activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: detaching message group affinity
Date Wed, 21 Jun 2006 06:11:41 GMT
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/

Mime
View raw message