Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ZEVsBuk0kBYflaXssOFwM3Kke4qQLRV1Dhp++z4F7v60Zag8M3360I7/yzEgghvGZB3WxnOuUXO/GMFlZyPRYL9LoodvVgXaXUalU3SIbLXZRBRl27GORZ7DM0ktjLuMq16zBWuvSv6nUmm+MD1QWrglQL1mkpy4kwl8cMOW5Kg=
Message-ID: <ec6e67fd0603241506r218a3a69gd24dea53a4a220cf@mail.gmail.com>
Date: Fri, 24 Mar 2006 15:06:48 -0800
From: "James Strachan" <james.strachan@gmail.com>
To: activemq-dev@geronimo.apache.org
Subject: Re: Non static WebClient?
In-Reply-To: <e01qef$t5t$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <e01qef$t5t$1@sea.gmane.org>

On 3/24/06, Greg Wilkins <gregw@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/