On 2/27/07, TonyLeigh <[EMAIL PROTECTED]> wrote:
Hi James, Thanks for the info, I understand what is happening now and can work around it in my application. James.Strachan wrote: > > So the reason for this is that currently there is a single thread per > connection processing server side operations. Normally these > operations are pretty fast; but if a producer is blocked, currently we > block the producer thread (to stopt it potentially sending more > messages and causing more trouble). > > So if you are getting into scenarios of blocking producers, its > probably worth having a separate connection for all your consumers. > Is the single thread per connection on the broker a deliberate design choice for ActiveMQ?
Yes - it generally minimises context switches in the broker which reduces latency and increases throughput
It would appear to violate the JMS spec in this situation of blocked producers.
Well the JMS spec doesn't really talk about flow control; so its kinda outside the spec. But yes I hear you. We could add an async dispatch layer on the broker side to solve this; which would cost some latency but remove any chance of a consumer being blocked by a blocked producer. The the new producer flow control in 5.x will fix this a bit better; by pushing more of the flow control back to the client.
Would it be possible to change ActiveMQ to have a separate thread for consumers on a per connection basis in the broker?
It'd be pretty easy yes. We welcome patches :) http://activemq.apache.org/contributing.html we could basically add an async dispatch layer into the Transport (as a TransportFilter) which could parallel commands into threads on the broker side (using the same thread for commands in the same session to preserve order but allow parallelism) -- James ------- http://radio.weblogs.com/0112098/
