[jboss-as7-dev] HornetQ subsystems in AS 7
Andrig Miller
anmiller at redhat.com
Wed Apr 6 16:20:00 EDT 2011
----- Original Message -----
> From: "Clebert Suconic" <csuconic at redhat.com>
> To: "Andrig Miller" <anmiller at redhat.com>
> Cc: "Brian Stansberry" <brian.stansberry at redhat.com>, "jboss-as7-dev at lists.jboss.org Development"
> <jboss-as7-dev at lists.jboss.org>
> Sent: Wednesday, April 6, 2011 2:17:15 PM
> Subject: Re: [jboss-as7-dev] HornetQ subsystems in AS 7
> Well... Topic subscriptions are just Queues.
>
> There are advantages of using the HornetQ API directly... Especially
> on Asynchronous ACKs.
>
> Although I don't understand exactly why you need a separate module on
> AS7 for this. This is just a simple POJO being accessed through the
> classloader. (hornetq-core.jar, and hornetq-core-client.jar)
>
Yeah, I don't see why that would be necessary either. Using the core API directly is fine, and can be exposed in the module along with JMS.
Andy
>
> On Apr 6, 2011, at 3:14 PM, Andrig Miller wrote:
>
> > Personal take on this, is that there shouldn't be two. The
> > astonishment below about only have queue's and not topics is a
> > direct result of this separation, because the implementation details
> > underneath JMS, in terms of HornetQ, is that there are only queues,
> > even though topics are fully support, but its still just a queue
> > underneath.
> >
> > This is a problem in my mind.
> >
> > Andy
> >
> > ----- Original Message -----
> >> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> >> To: "jboss-as7-dev at lists.jboss.org Development"
> >> <jboss-as7-dev at lists.jboss.org>, "Clebert Suconic"
> >> <csuconic at redhat.com>
> >> Sent: Wednesday, April 6, 2011 1:15:04 PM
> >> Subject: [jboss-as7-dev] HornetQ subsystems in AS 7
> >> Copied below is a discussion we had today on #jboss-as7 in IRC that
> >> I'm
> >> copying here to get input from the HQ folks.
> >>
> >> AS 7 currently has 2 HQ-related subsystems, "messaging" which
> >> provides
> >> core HQ, and "jms" which brings in JMS spec compliance. The gist of
> >> the
> >> discussion is 1) whether this separation is overly unintuitive and
> >> 2)
> >> if
> >> it's necessary, is the name "messaging" for the core HQ subsystem
> >> too
> >> likely to lead users to assume it's where JMS topic/queue creation
> >> is
> >> done.
> >>
> >> The conversation is below. It carried on after the following;
> >> please
> >> see
> >> http://echelog.matzon.dk/logs/browse/jboss-as7/1302040800 if you
> >> are
> >> interested.
> >>
> >> pilhuhn: Also I am astonished that Q s are present , but not Topics
> >> [1:52pm] bstansberry: pilhuhn: there are topics in the jms
> >> subsystem
> >> [1:53pm] bstansberry: the "messaging" subsystem is very oriented
> >> toward
> >> core HornetQ
> >> [1:54pm] bstansberry: Nihility: ^^^ reminds me of our discussion w/
> >> paul
> >> re: the JGroups subsystem, where we decided it was silly to give a
> >> "generic" name to a subsystem that was not exposing a standard API
> >> [1:55pm] bstansberry: same applies to subsystem=messaging
> >> [1:55pm] pilhuhn: so Qs are in both? messaging and jms? feels
> >> strange
> >> [1:55pm] Nihility: bstansberry: makes sense
> >> [1:55pm] Nihility: bstansberry: sort of
> >> [1:55pm] Nihility: bstansberry: another example is subsystem=web
> >> [1:56pm] Nihility: bstansberry: which is jboss web
> >> [1:56pm] bstansberry: well, that at least is exposing the Servlet
> >> spec
> >> [1:56pm] dmlloyd: shared global bindings are a nasty little problem
> >> [1:56pm] Nihility: i think our goal should just be to have
> >> subsystem
> >> names
> >> [1:56pm] Nihility: that are intuitive easy to understand
> >> [1:57pm] Nihility: jgroups vs group-communication is basically the
> >> same
> >> to me
> >> [1:57pm] dmlloyd: jgroups is unambiguous and concise imo
> >> [1:57pm] bstansberry: yes, that's decided
> >> [1:57pm] Nihility: yes
> >> [1:57pm] dmlloyd: hornetq should be hornetq
> >> [1:57pm] Nihility: the reason for messaging and jms is different
> >> [1:57pm] pilhuhn: I think it needs to be clear that for an enduse,
> >> that
> >> he wants to have a jms/queue and not a messaging/queue when doing
> >> jms
> >> [1:58pm] dmlloyd: jms should be jms
> >> [1:58pm] Nihility: they realy do have two subsystems
> >> [1:58pm] dmlloyd: if there is such a generic notion
> >> [1:58pm] bstansberry: right, so calling hornetq "messaging" is not
> >> intuitive
> >> [1:58pm] Nihility: they have this notion of a lightweight topic
> >> [1:58pm] bstansberry: people will gravitate toward it
> >> [1:59pm] pilhuhn: Yeah leightweight.. it will float in the clouds
> >> [1:59pm] Nihility: and thats what they think is a real messaging
> >> api
> >> [1:59pm] pilhuhn: .oO( DId I win as BS-Bingo? )
> >> [1:59pm] Nihility: jms is just something extra they do for the spec
> >> [1:59pm] Nihility: with extra requirements etc
> >> [1:59pm] Nihility: so its like a higher level layer
> >> [1:59pm] Nihility: so they have core messaging
> >> [1:59pm] Nihility: and they have jms
> >> [1:59pm] Nihility: and togheter thats hornetq
> >> [1:59pm] bstansberry: good point
> >> [2:00pm] bstansberry: ok, no JIRA, at least not from me
> >> [2:01pm] bstansberry: instead, a dev list thread and the HQ people
> >> can
> >> deal with it
> >> [2:01pm] pilhuhn: The admin that wants to use a MessageDrivenBean
> >> does
> >> not really care about that separation
> >> [2:02pm] Nihility: the separation is more because you can run hq
> >> without
> >> starting the jms services
> >> [2:02pm] Nihility: and they have separate configuration
> >> [2:02pm] pilhuhn: yep
> >> [2:02pm] Nihility: although you could collapse the two
> >> [2:02pm] Nihility: emuckenhuber and i debated that for awhile
> >> [2:02pm] Nihility: we had a hard time deciding
> >> [2:03pm] pilhuhn: What I want to express (and that targets rather
> >> us
> >> with JON and the console) is that for this said admin it needs to
> >> be
> >> totally clear that he wants to go to subsys/jms/queue
> >>
> >> --
> >> Brian Stansberry
> >> Principal Software Engineer
> >> JBoss by Red Hat
> >> _______________________________________________
> >> jboss-as7-dev mailing list
> >> jboss-as7-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
More information about the jboss-as7-dev
mailing list