James, Yeah, I'm sure it would be straightforward for a good JMS provider to support.
My original point was just about how the JMS spec has some limitations and threading is one of them. Control is the thing here, in high performant apps I really want complete control over threading - I want to create dispatch threads, not the provider, and choose which threads handle which subscriptions from which transports. In fact I want total control over all the components I build systems with, not an unreasonable requirement I'm sure we'd all agree. JMS has implicit threading in its model, I just don't believe this is a good thing for everyone all the time. Regards, Colin. http://hermesjms.com > -----Original Message----- > From: James Strachan [mailto:[EMAIL PROTECTED] > Sent: 20 September 2006 17:13 > To: [email protected] > Subject: Re: QPID/HermesJMS > > On 9/19/06, Colin Crist <[EMAIL PROTECTED]> wrote: > > > > One commonly cited one is threading, if anyone has used RV for > > > > example, its model of having dispatch queues (not to be > > > confused with > > > > transport queues) onto which messages are placed by > listeners (i.e. > > > > subscriptions) totally decouples the subscription from > the final > > > > message callback. This model is very flexible letting > you dispatch > > > > messages from timers as well as transports. > > > > > > I don't quite follow. Whats to stop a JMS provider dispatching > > > messages from N transports and M timers to a single JMS > session and > > > using a single thread or a thread pool to execute the > > > MessageListener's on the consumers? > > > > Nothing, but its not in the spec so there are no > implementations (that > > I know of) that let you. > > FWIW it would be trivial to write a little timer Transport > implementation for ActiveMQ which could act as a filter to > any other transport but fire timer events to consumers > whenever it wished to do just what you need etc. > > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > >
