On 9/15/06, Colin Crist <[EMAIL PROTECTED]> wrote:
One benefit of having a more AMQP friendly API that the JMS layer uses is that you can avoid being bound into some of the shortcomings JMS imposes. 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? -- James ------- http://radio.weblogs.com/0112098/
