[jboss-as7-dev] HornetQ subsystems in AS 7

[Clebert Suconic]

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)


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