Re: Optimising PrefetchSubscription.dispatchPending() ideas

[Mike Kelley <mk...@rearden.com>]

Hi David,

I'm new to ActiveMQ and unfamiliar with the code (albeit w/experience in
JMS), so forgive me if this is a silly question: do the performance
issues/fixes discussed affect non-durable subscriptions (w/non-persistent
messages) as well?

Mike


David Sitsky-2 wrote:
> 
> Rob and I did some performance enhancements with queues so that a 
> Queue.send() call was decoupled from the dispatch processing.  In the 
> past, depending on the state of the consumers, a Queue.send() call could 
> take a significant amount of time.  We changed it so that a single 
> thread was responsible for dispatching messages, which avoided a lot of 
> lock contention.  It also meant a Queue.send() returned as quickly as 
> possible.
> 
> I imagine a similar change could be done for Topics, since from what I 
> can tell, a Topic.send() call currently does its dispatch processing in 
> the same call.
> 
> Cheers,
> David
> 

-- 
View this message in context: http://www.nabble.com/Optimising-PrefetchSubscription.dispatchPending%28%29-ideas-tp15359726s2354p16207231.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: Optimising PrefetchSubscription.dispatchPending() ideas

[David Sitsky <si...@nuix.com>]

Hi Mike,

If you are talking about non-persistent messages for queues, then yes, 
the performance should be much better.  If you are talking about topics 
- that is another story.  My application was primarily queue-based, so I 
wasn't concerned with the performance of topics.

Cheers,
David

Mike Kelley wrote:
> Hi David,
> 
> I'm new to ActiveMQ and unfamiliar with the code (albeit w/experience in
> JMS), so forgive me if this is a silly question: do the performance
> issues/fixes discussed affect non-durable subscriptions (w/non-persistent
> messages) as well?
> 
> Mike
> 
> 
> David Sitsky-2 wrote:
>> Rob and I did some performance enhancements with queues so that a 
>> Queue.send() call was decoupled from the dispatch processing.  In the 
>> past, depending on the state of the consumers, a Queue.send() call could 
>> take a significant amount of time.  We changed it so that a single 
>> thread was responsible for dispatching messages, which avoided a lot of 
>> lock contention.  It also meant a Queue.send() returned as quickly as 
>> possible.
>>
>> I imagine a similar change could be done for Topics, since from what I 
>> can tell, a Topic.send() call currently does its dispatch processing in 
>> the same call.
>>
>> Cheers,
>> David
>>
> 


-- 
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://www.nuix.com                            Fax: +61 2 9212 6902