Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 66.249.92.175 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=MEItx8Yq+2WLU18htUJ+ocXmYPJzjD1T+HOpIrJmhvd/6i87hA8/nmpn/kn5UYdda5owdiShHTLozOxCjm2m1e+Hn2NoUa6ZsGmNGqafhnUtApvOJsSnoEwoAdE9Kt9gHz9vLkIDEZcIbjZjGC9MET/MFGFjsAR2epinj+F9h+A=
Message-ID: <ec6e67fd0606202314g67315e84rd01b50ce2aecbb80@mail.gmail.com>
Date: Wed, 21 Jun 2006 07:14:00 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: activemq-users@geronimo.apache.org
Subject: Re: detaching message group affinity
In-Reply-To: <ec6e67fd0606202311w7780648cy6556b177152839cd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <a17839be0606161754g531010afhb4c2c68ed6e0dd7f@mail.gmail.com>
	 <a17839be0606190811g4d27f7b7l2576b0cf4fb82402@mail.gmail.com>
	 <ec6e67fd0606190817h15083f56tbf95a667687db1ee@mail.gmail.com>
	 <4957209.post@talk.nabble.com>
	 <ec6e67fd0606201010l1360e17dp4f8c9d987da9e01a@mail.gmail.com>
	 <a17839be0606201123s22bb732qf44d46a37f85b88@mail.gmail.com>
	 <ec6e67fd0606202215u6abeb9d3j5b8ad6a1f62e0740@mail.gmail.com>
	 <a17839be0606202241j3e1ab2f3jcc05b542053b6ff9@mail.gmail.com>
	 <a17839be0606202251m6e31b71eq591783c4e5569c80@mail.gmail.com>
	 <ec6e67fd0606202311w7780648cy6556b177152839cd@mail.gmail.com>

BTW a nice way to clean up dead conversations could just be to time them out.

On the Lingo project we have a useful Map implementation class which
if the key is not used within a time window its evicted from RAM; we
could maybe use this with the SimpleMessageGroupMap to clean up
conversations after a period of inactivity.

http://lingo.codehaus.org/maven/apidocs/org/logicblaze/lingo/util/TimeoutMap.html

On 6/21/06, James Strachan <james.strachan@gmail.com> wrote:
> LOL. No worries - I was being lazy too not showing you how to do it
> :). Still glad to hear it was possible for you to figure it out :)
>
> On 6/21/06, Sanjiv Jivan <sanjiv.jivan@gmail.com> wrote:
> > On 6/21/06, Sanjiv Jivan <sanjiv.jivan@gmail.com> wrote:
> > >
> > >
> > >
> > >  On 6/21/06, James Strachan <james.strachan@gmail.com> wrote:
> > > >
> > > > BTW what do you do if the JVM running the conversation dies?
> > >
> > >
> > >  If the JVM running the conversation dies, the message group for this
> > > converation should fail over to another server where an exception will be
> > > raised indicating that the conversation is not recognized on this server.
> > > The client will see this exception message and can then restart the
> > > conversation against a new server.
> > >
> > > It sounds like then if you don't want to close a message group (for
> > > > fear of closing another message group) then you could consider
> > > >
> > > > (i) using an alternative MessageGroupMap implementation which doesn't
> > > > use hash buckets - this could use lots more RAM if you have a large
> > > > number of JMSXGroupID values - and there is the chance of a memory
> > > > leak if you keep generating values and don't close them down but you
> > > > may be happy to pay that cost
> > > >
> > > >
> > > > http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/broker/region/group/MessageGroupMap.html
> > > >
> > > > i.e. use the SimpleMessageGroupMap rather than the default which uses
> > > > hash buckets.
> > > >
> > > > (ii) to close a conversation, just close the message consumer.
> > > >
> > > > Maybe you need (i)?
> > >
> > >
> > >  Yes, SimpleMessageGroupMap seems like what I need. In my usecase there
> > > will not be many conversations (50 atmost) and I will be able to write a
> > > cleanup routine to close dead conversations.
> > >
> > > Is there a top level factory/property I can set using the Spring config
> > > (like the connection factory or the destination) to cause it internally use
> > > SimpleMessageGroupMap ?
> > >
> > >
> >
> > I'll figure this out. Kinda late here and I was getting lazy to dig through
> > the source now.. Sorry :)
> >
> >   Thanks,
> > >  Sanjiv
> > >
> > > On 6/20/06, Sanjiv Jivan <sanjiv.jivan@gmail.com> wrote:
> > > > > On 6/20/06, James Strachan <james.strachan@gmail.com> wrote:
> > > > > >
> > > > > > On 6/20/06, Thomas Swindells <tswindells@ndsuk.com > wrote:
> > > > > > > James.Strachan wrote:
> > > > > > > >
> > > > > > > > On 6/19/06, Sanjiv Jivan <sanjiv.jivan@gmail.com> wrote:
> > > > > > > >> > 2. Is there a way to detach a message group affinity to a
> > > > > > particular
> > > > > > > >> broker.
> > > > > > > >>
> > > > > > > >> >Just set JMSXGroupSeq to zero on the last message which
> > > > 'closes' the
> > > > > > > >> >message group so if another message is sent in the future with
> > > > the
> > > > > > > >> >same group ID it will be reassigned to a new consumer.
> > > > > > > >>
> > > > > > > >> >message.setIntProperty("JMSXGroupSeq", 0);
> > > > > > > >>
> > > > > > > >> This would reset all the affinity of all the message groups,
> > > > right?
> > > > > > > >
> > > > > > > > No - just the message group for the JMSXGroupId setting.
> > > > > > > > I should have been more clear... to clear message group FOO use
> > > > > > > >
> > > > > > > > message.setStringProperty("JMSXGroupID", "FOO");
> > > > > > > > message.setIntProperty("JMSXGroupSeq", 0);
> > > > > > > >
> > > > > > > Reading the Message group page
> > > > > > > (http://activemq.org/site/message-groups.html) there is probably a
> > > > minor
> > > > > > bug
> > > > > > > here in that it would close all messsage groups with the same Hash
> > > > as
> > > > > > "FOO",
> > > > > > > although in practice for a well designed system expecting that msg
> > > > > > groups
> > > > > > > could change this shouldn't be a problem. Of course the chances of
> > > > a
> > > > > > hash
> > > > > > > clash for relatively short group id's is pretty tiny.
> > > > > >
> > > > > > Yeah - hashing collisions should be fairly unlikely - though its a
> > > > RAM
> > > > > > v risk tradeoff - the larger the number of hash buckets, the more
> > > > RAM
> > > > > > used but the less likely a collision.
> > > > > >
> > > > > > Though worse case a message group is closed and reopened - which
> > > > just
> > > > > > rebalances the association of message groups to consumers so it
> > > > > > doesn't cause much harm (*).
> > > > >
> > > > >
> > > > > This would cause harm if a message group is used as a basis of a
> > > > stateful
> > > > > conversation with the chosen server (which embeds a broker)which I how
> > > > I
> > > > > require to use them in my usecase. Is not like a stateless stock quote
> > > > > request which any server can respond to.. its more like
> > > > > startConversation(A), getResults(A) and if getResults(A) goes to the
> > > > wrong
> > > > > server, its an error condition since the conversation was started with
> > > > > another server. I do not want to get in the business of state
> > > > replicating
> > > > > servers, just want to partition conversation based load based (rather
> > > > that
> > > > > individual request based load balancing).
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > James
> > > > -------
> > > > http://radio.weblogs.com/0112098/
> > > >
> > >
> > >
> > >
> >
> >
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>


-- 

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