activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: Non static WebClient?
Date Sat, 25 Mar 2006 07:48:19 GMT


OK I understand that now.   Shall I'll modify the patch so that it can either
share or create individual consumers for a queue.   Or do you think with
the tweaks non-shared is sufficient?

If we keep shared, I'll add a reference count on the shared consumer so we 
know when to clean it up.

For the non-shared consumer, my current patch will close an idle
consumer that is not being long-polled anymore.   Does a close 
return any prefetched messages to the queue?


James Strachan wrote:
> On 3/24/06, Greg Wilkins <> wrote:
>>I was trying to tidy up the Ajax code so that consumers closed when
>>sessions timeout (or long polls stop coming).   But the queueConsumer
>>map in WebClient is static and key only by destination, which means:
>> + You can only have one consumer per queue.    I can imagine Ajax
>>   apps that want to hand out messages to one of many clients and thus
>>   having multiple consumers would be a good way to do this.
>> + As it stands, you don't know when the consumer is no longer needed.
>>   So it will live forever even if all sessions timeout.
>>I've reworked the code so that queue consumers are associated with
>>the httpSession (just as topic consumers) and they use the common
>>jms session. unsubscribe now closes consumers as will long poll
>>timeout and ending the session.
>>But I don't want to check it in, as I don't understand why the
>>consumers were static in the first place.  Some effort was put
>>into the static code and recovering the map from context
>>attributes etc.  So I'd like to double check that I'm not
>>missing something?
>>I've attached a patch and would appreciate any comments.
> I think I remember now why it was done like that.
> Topic consumers don't really interfere with each other, they are
> atomic things; if the come and go it doesn't affect anyone else much.
> Queue consumers however do compete with each other;  creating a single
> consumer will effectively grab a whole bunch of messages ready to be
> dispatched to the client when ready (which is generally as soon as is
> possible with normal JMS clients).
> The worry is messages will just sit there in the consumer, not being
> consumed by available consumers. So I think the idea was for web
> clients to pull messages out of a single consumer to minimise the
> number of messages that get stuck in these inbound message buffers.
> However having a consumer per subscription & http session is much
> cleaner - so a better way is maybe to tweak ActiveMQ to work nicer in
> this slightly different web-subscription model. e.g. we can set the
> prefetchSize to 1 or even 0 to minimise the number of messages that
> just end up getting stuck in a consumer before they start being
> actually consumed.
> One change we should add to ActiveMQ to further minimise this problem
> is that if a consumer is created - and it then recieves messages and
> then does not process them within some time period, the messages are
> given back to the server so that they can be dispatched to another
> consumer (together with lowering the priority of the consumer). Then
> if lots of consumers are created that time out, the messages are taken
> back and given to a more active consumer.
> --
> James
> -------

View raw message