From: "Clebert Suconic" <csuconic(a)redhat.com>
To: "Andrig Miller" <anmiller(a)redhat.com>
Cc: "Brian Stansberry" <brian.stansberry(a)redhat.com>,
"jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)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(a)redhat.com>
>> To: "jboss-as7-dev(a)lists.jboss.org Development"
>> <jboss-as7-dev(a)lists.jboss.org>, "Clebert Suconic"
>> <csuconic(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev