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 Tue, 20 Jun 2006 17:10:09 GMT
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 (*).

(*) if there are lots of in-fight messages in-process and more
messages are sent after the close, then there's a small window where
ordering could break. So its generally easier to kill the consumer
who's consuming a message group to ensure that no overlap occurs.

-- 

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

Mime
View raw message