James, 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? cheers James Strachan wrote: > On 3/24/06, Greg Wilkins <[EMAIL PROTECTED]> wrote: > >>Hi, >> >>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 > ------- > http://radio.weblogs.com/0112098/ >
