activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: [Spam: 5.0] Consumer blocking when session created on same connection as blocked producer
Date Tue, 27 Feb 2007 15:01:24 GMT
On 2/27/07, TonyLeigh <tleigh@ndsuk.com> 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/

Mime
View raw message