Non static WebClient?

[Greg Wilkins <gr...@mortbay.com>]

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.

cheers

Re: Non static WebClient?

[James Strachan <ja...@gmail.com>]

On 3/25/06, Greg Wilkins <gr...@mortbay.com> wrote:
>
> 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?

Yes it does - so that should be good enough.

We can also ensure that the prefetch is set quite small for web based
consumers (say 1 message).

Lets go with the non-shared version as its a bit cleaner.

--

James
-------
http://radio.weblogs.com/0112098/

Re: Non static WebClient?

[Greg Wilkins <gr...@mortbay.com>]

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 <gr...@mortbay.com> 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/
> 

Re: Non static WebClient?

[James Strachan <ja...@gmail.com>]

On 3/24/06, Greg Wilkins <gr...@mortbay.com> 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/