You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Sanjiv Jivan <sa...@gmail.com> on 2006/06/17 02:54:35 UTC
detaching message group affinity
The Message Group functionality of Active MQ 4.0 is really neat. I have a
couple of questions regarding this
1. Is this feature fully supported/tested with the P2P discovery style
broker topology? Are they any test cases or samples I can try. I looked for
them in the source but wasn't able to locate them. And when I tried running
such a scenario, I did not see a proper load balancing (even round robin
style) of message groups across available brokers. When messages belonging
to different message groups are sent, oftentimes only one or a small
percentage of running brokers are chosen as recipients. As a result I end up
with some brokers that are overloaded while others are sitting idle.
2. Is there a way to detach a message group affinity to a particular broker.
In my use case, a message group marks a conversation which is a sequence of
related calls to a recipient. However when a business conversation ends, I
would like to have a way of detaching the affinity of a message
group/conversation-id with the broker so that at a later point if a
conversation with the same ID is made, rather than simply going to the
initially chosen broker from the previous conversation, a broker is chosen
based on load balancing criteria. For example a message header
("*-*JMSXGroupID",
<messagegroup-id>) could be used to detach a message group affinity to a
broker.
Thanks,
Sanjiv
Re: detaching message group affinity
Posted by James Strachan <ja...@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 <ja...@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 <sa...@gmail.com> wrote:
> > On 6/21/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > >
> > >
> > >
> > > On 6/21/06, James Strachan <ja...@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 <sa...@gmail.com> wrote:
> > > > > On 6/20/06, James Strachan <ja...@gmail.com> wrote:
> > > > > >
> > > > > > On 6/20/06, Thomas Swindells <tswindells@ndsuk.com > wrote:
> > > > > > > James.Strachan wrote:
> > > > > > > >
> > > > > > > > On 6/19/06, Sanjiv Jivan <sa...@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/
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
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 <sa...@gmail.com> wrote:
> On 6/21/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> >
> >
> >
> > On 6/21/06, James Strachan <ja...@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 <sa...@gmail.com> wrote:
> > > > On 6/20/06, James Strachan <ja...@gmail.com> wrote:
> > > > >
> > > > > On 6/20/06, Thomas Swindells <tswindells@ndsuk.com > wrote:
> > > > > > James.Strachan wrote:
> > > > > > >
> > > > > > > On 6/19/06, Sanjiv Jivan <sa...@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/
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/21/06, Sanjiv Jivan <sa...@gmail.com> wrote:
>
>
>
> On 6/21/06, James Strachan <ja...@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 <sa...@gmail.com> wrote:
> > > On 6/20/06, James Strachan <ja...@gmail.com> wrote:
> > > >
> > > > On 6/20/06, Thomas Swindells <tswindells@ndsuk.com > wrote:
> > > > > James.Strachan wrote:
> > > > > >
> > > > > > On 6/19/06, Sanjiv Jivan <sa...@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/
> >
>
>
>
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/21/06, James Strachan <ja...@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 ?
Thanks,
Sanjiv
On 6/20/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > On 6/20/06, James Strachan <ja...@gmail.com> wrote:
> > >
> > > On 6/20/06, Thomas Swindells <ts...@ndsuk.com> wrote:
> > > > James.Strachan wrote:
> > > > >
> > > > > On 6/19/06, Sanjiv Jivan <sa...@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/
>
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
BTW what do you do if the JVM running the conversation dies?
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)?
On 6/20/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> On 6/20/06, James Strachan <ja...@gmail.com> wrote:
> >
> > On 6/20/06, Thomas Swindells <ts...@ndsuk.com> wrote:
> > > James.Strachan wrote:
> > > >
> > > > On 6/19/06, Sanjiv Jivan <sa...@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/
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/20/06, James Strachan <ja...@gmail.com> wrote:
>
> On 6/20/06, Thomas Swindells <ts...@ndsuk.com> wrote:
> > James.Strachan wrote:
> > >
> > > On 6/19/06, Sanjiv Jivan <sa...@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).
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
On 6/20/06, Thomas Swindells <ts...@ndsuk.com> wrote:
> James.Strachan wrote:
> >
> > On 6/19/06, Sanjiv Jivan <sa...@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/
Re: detaching message group affinity
Posted by Thomas Swindells <ts...@ndsuk.com>.
James.Strachan wrote:
>
> On 6/19/06, Sanjiv Jivan <sa...@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.
Thomas
--
View this message in context: http://www.nabble.com/detaching-message-group-affinity-t1801568.html#a4957209
Sent from the ActiveMQ - User forum at Nabble.com.
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
have updated the wiki...
http://activemq.org/site/message-groups.html
On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> >
> > On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > > >
> > > >
> > > > > Who is the owner of the "JMSXGroupID" to broker mapping? Is it the
> > JMS
> > > > > Connection or a JMSSession? I need to send messages by different
> > Message
> > > > > Groups from the same client application. I would like to understand
> > if I
> > > > > need to create separate JMS Connections for each message group based
> > > > > conversation, or separate JMS Sessions would suffice. A quick look
> > at
> > > > the
> > > > > source seems to indicate that Message Groups are held at the JMS
> > > > connection
> > > > > level (ActiveMQConnectionMetaData). Can you confirm?
> > > >
> > > > A broker manages Message Groups for its consumers. Its nothing to do
> > > > with connections per se - its purely a mapping of JMSXGroupID to
> > > > message consumer in a broker.
> > >
> > >
> > > A consumer being the value in JMSReplyTo?
> >
> > Not necessarily - a consumer being some POJO created via
> > Session.createMessageConsumer().
> >
> > But if the consumers are using temporary queues/topics then they are
> > nearly the same thing.
> >
> >
> > > I guess what I'm having difficulty
> > > understanding is where is the correlation between a single message with
> > "
> > > message.setIntProperty("JMSXGroupSeq", 0);" to MessageGroupID being
> > made. Is
> > > it based on JMSReplyTo value provided by the producer sending the
> > message?
> >
> >
> > If someone is sending a message and they want to 'close' a message
> > group, they set the JMSXGroupSeq header along with the JMSXGroupID
> > header.
>
>
> aha, this was the thing I was missing. ie JMSXGroupID *and* JMSXGroupSeq
> should be send in the same message for it to detach the message group
> affinity for the specified JMSXGroupID.
>
> If some other node who is not a JMS sender wants to close a message
> > group, you could always just send a dummy message.
> >
> >
> > > What is the expected behaviour in such a scenario (this is related to
> > issue
> > > AMQ-760): A network of 2 brokers has been set up. A client sends several
> > > messages to MG1 and MG2 which are received by SERVER1 and SERVER2
> > > respectively. The client process terminates (ie the JMSConenction,
> > > session etc are destroyed). The client comes up an send messages to MG1
> > and
> > > MG2. Is is guaranteed that MG1 and MG2 go to the designated servers from
> > the
> > > previous run (SERVER1 and SERVER2 respectively).
> >
> > Message groups is a broker-side thing; the only thing which affects
> > which consumer is associated with a message group is
> >
> > * when the consumer is closed (e.g. as a result of a Connection
> > close), its message groups are put back in the pool to be re-assigned
> > to a consumer
>
>
> This is extremely useful to know. Maybe you can add this info too on the
> ActiveMQ web site.
>
> * if the message group is explicitly closed by a message containing a
> > JMSXGroupId and a JMSXGroupSeq of value 0
> >
> > --
>
>
> With this info I now have a better understanding of how things work and have
> a bunch of things that I can try. Will report back with results/ further
> questions.
>
> I realize you guys are very busy so thanks so much for being patient and
> answering my questions in detail.
>
> Sanjiv
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/19/06, James Strachan <ja...@gmail.com> wrote:
>
> On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > >
> > >
> > > > Who is the owner of the "JMSXGroupID" to broker mapping? Is it the
> JMS
> > > > Connection or a JMSSession? I need to send messages by different
> Message
> > > > Groups from the same client application. I would like to understand
> if I
> > > > need to create separate JMS Connections for each message group based
> > > > conversation, or separate JMS Sessions would suffice. A quick look
> at
> > > the
> > > > source seems to indicate that Message Groups are held at the JMS
> > > connection
> > > > level (ActiveMQConnectionMetaData). Can you confirm?
> > >
> > > A broker manages Message Groups for its consumers. Its nothing to do
> > > with connections per se - its purely a mapping of JMSXGroupID to
> > > message consumer in a broker.
> >
> >
> > A consumer being the value in JMSReplyTo?
>
> Not necessarily - a consumer being some POJO created via
> Session.createMessageConsumer().
>
> But if the consumers are using temporary queues/topics then they are
> nearly the same thing.
>
>
> > I guess what I'm having difficulty
> > understanding is where is the correlation between a single message with
> "
> > message.setIntProperty("JMSXGroupSeq", 0);" to MessageGroupID being
> made. Is
> > it based on JMSReplyTo value provided by the producer sending the
> message?
>
>
> If someone is sending a message and they want to 'close' a message
> group, they set the JMSXGroupSeq header along with the JMSXGroupID
> header.
aha, this was the thing I was missing. ie JMSXGroupID *and* JMSXGroupSeq
should be send in the same message for it to detach the message group
affinity for the specified JMSXGroupID.
If some other node who is not a JMS sender wants to close a message
> group, you could always just send a dummy message.
>
>
> > What is the expected behaviour in such a scenario (this is related to
> issue
> > AMQ-760): A network of 2 brokers has been set up. A client sends several
> > messages to MG1 and MG2 which are received by SERVER1 and SERVER2
> > respectively. The client process terminates (ie the JMSConenction,
> > session etc are destroyed). The client comes up an send messages to MG1
> and
> > MG2. Is is guaranteed that MG1 and MG2 go to the designated servers from
> the
> > previous run (SERVER1 and SERVER2 respectively).
>
> Message groups is a broker-side thing; the only thing which affects
> which consumer is associated with a message group is
>
> * when the consumer is closed (e.g. as a result of a Connection
> close), its message groups are put back in the pool to be re-assigned
> to a consumer
This is extremely useful to know. Maybe you can add this info too on the
ActiveMQ web site.
* if the message group is explicitly closed by a message containing a
> JMSXGroupId and a JMSXGroupSeq of value 0
>
> --
With this info I now have a better understanding of how things work and have
a bunch of things that I can try. Will report back with results/ further
questions.
I realize you guys are very busy so thanks so much for being patient and
answering my questions in detail.
Sanjiv
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
>
>
>
> Unfortunately "JMSXGroupSeq" does not seem to be resetting the message
> group for the corresponding "JMSXGroupID". I'm certain that I'm setting
> these properties correctly (even verified by stepping through debugger). As
> mentioned in my previous mail, I can provide you with the complete example
> that demonstrates this.
>
> Sanjiv
>
>
>
message.setIntProperty("JMSXGroupSeq", *1*); seems to be resetting the
Message Group but it seems to be doing so even for the "current" message. ie
the message that has this property "JMSXGroupSeq" is going to another broker
and not the one that the message group had previously attached itself to. So
sending a dummy message with JMSXGroupSeq after the last real message of the
conversation could be whats required. Can you confirm?
Thanks,
Sanjiv
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/19/06, James Strachan <ja...@gmail.com> wrote:
>
> On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > >
> > >
> > > > Who is the owner of the "JMSXGroupID" to broker mapping? Is it the
> JMS
> > > > Connection or a JMSSession? I need to send messages by different
> Message
> > > > Groups from the same client application. I would like to understand
> if I
> > > > need to create separate JMS Connections for each message group based
> > > > conversation, or separate JMS Sessions would suffice. A quick look
> at
> > > the
> > > > source seems to indicate that Message Groups are held at the JMS
> > > connection
> > > > level (ActiveMQConnectionMetaData). Can you confirm?
> > >
> > > A broker manages Message Groups for its consumers. Its nothing to do
> > > with connections per se - its purely a mapping of JMSXGroupID to
> > > message consumer in a broker.
> >
> >
> > A consumer being the value in JMSReplyTo?
>
> Not necessarily - a consumer being some POJO created via
> Session.createMessageConsumer().
>
> But if the consumers are using temporary queues/topics then they are
> nearly the same thing.
>
>
> > I guess what I'm having difficulty
> > understanding is where is the correlation between a single message with
> "
> > message.setIntProperty("JMSXGroupSeq", 0);" to MessageGroupID being
> made. Is
> > it based on JMSReplyTo value provided by the producer sending the
> message?
>
>
> If someone is sending a message and they want to 'close' a message
> group, they set the JMSXGroupSeq header along with the JMSXGroupID
> header.
>
> If some other node who is not a JMS sender wants to close a message
> group, you could always just send a dummy message.
>
>
> > What is the expected behaviour in such a scenario (this is related to
> issue
> > AMQ-760): A network of 2 brokers has been set up. A client sends several
> > messages to MG1 and MG2 which are received by SERVER1 and SERVER2
> > respectively. The client process terminates (ie the JMSConenction,
> > session etc are destroyed). The client comes up an send messages to MG1
> and
> > MG2. Is is guaranteed that MG1 and MG2 go to the designated servers from
> the
> > previous run (SERVER1 and SERVER2 respectively).
>
> Message groups is a broker-side thing; the only thing which affects
> which consumer is associated with a message group is
>
> * when the consumer is closed (e.g. as a result of a Connection
> close), its message groups are put back in the pool to be re-assigned
> to a consumer
>
> * if the message group is explicitly closed by a message containing a
> JMSXGroupId and a JMSXGroupSeq of value 0
Unfortunately "JMSXGroupSeq" does not seem to be resetting the message group
for the corresponding "JMSXGroupID". I'm certain that I'm setting these
properties correctly (even verified by stepping through debugger). As
mentioned in my previous mail, I can provide you with the complete example
that demonstrates this.
Sanjiv
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> >
> >
> > > Who is the owner of the "JMSXGroupID" to broker mapping? Is it the JMS
> > > Connection or a JMSSession? I need to send messages by different Message
> > > Groups from the same client application. I would like to understand if I
> > > need to create separate JMS Connections for each message group based
> > > conversation, or separate JMS Sessions would suffice. A quick look at
> > the
> > > source seems to indicate that Message Groups are held at the JMS
> > connection
> > > level (ActiveMQConnectionMetaData). Can you confirm?
> >
> > A broker manages Message Groups for its consumers. Its nothing to do
> > with connections per se - its purely a mapping of JMSXGroupID to
> > message consumer in a broker.
>
>
> A consumer being the value in JMSReplyTo?
Not necessarily - a consumer being some POJO created via
Session.createMessageConsumer().
But if the consumers are using temporary queues/topics then they are
nearly the same thing.
> I guess what I'm having difficulty
> understanding is where is the correlation between a single message with "
> message.setIntProperty("JMSXGroupSeq", 0);" to MessageGroupID being made. Is
> it based on JMSReplyTo value provided by the producer sending the message?
If someone is sending a message and they want to 'close' a message
group, they set the JMSXGroupSeq header along with the JMSXGroupID
header.
If some other node who is not a JMS sender wants to close a message
group, you could always just send a dummy message.
> What is the expected behaviour in such a scenario (this is related to issue
> AMQ-760): A network of 2 brokers has been set up. A client sends several
> messages to MG1 and MG2 which are received by SERVER1 and SERVER2
> respectively. The client process terminates (ie the JMSConenction,
> session etc are destroyed). The client comes up an send messages to MG1 and
> MG2. Is is guaranteed that MG1 and MG2 go to the designated servers from the
> previous run (SERVER1 and SERVER2 respectively).
Message groups is a broker-side thing; the only thing which affects
which consumer is associated with a message group is
* when the consumer is closed (e.g. as a result of a Connection
close), its message groups are put back in the pool to be re-assigned
to a consumer
* if the message group is explicitly closed by a message containing a
JMSXGroupId and a JMSXGroupSeq of value 0
--
James
-------
http://radio.weblogs.com/0112098/
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/19/06, James Strachan <ja...@gmail.com> wrote:
>
>
> > Who is the owner of the "JMSXGroupID" to broker mapping? Is it the JMS
> > Connection or a JMSSession? I need to send messages by different Message
> > Groups from the same client application. I would like to understand if I
> > need to create separate JMS Connections for each message group based
> > conversation, or separate JMS Sessions would suffice. A quick look at
> the
> > source seems to indicate that Message Groups are held at the JMS
> connection
> > level (ActiveMQConnectionMetaData). Can you confirm?
>
> A broker manages Message Groups for its consumers. Its nothing to do
> with connections per se - its purely a mapping of JMSXGroupID to
> message consumer in a broker.
A consumer being the value in JMSReplyTo? I guess what I'm having difficulty
understanding is where is the correlation between a single message with "
message.setIntProperty("JMSXGroupSeq", 0);" to MessageGroupID being made. Is
it based on JMSReplyTo value provided by the producer sending the message?
What is the expected behaviour in such a scenario (this is related to issue
AMQ-760): A network of 2 brokers has been set up. A client sends several
messages to MG1 and MG2 which are received by SERVER1 and SERVER2
respectively. The client process terminates (ie the JMSConenction,
session etc are destroyed). The client comes up an send messages to MG1 and
MG2. Is is guaranteed that MG1 and MG2 go to the designated servers from the
previous run (SERVER1 and SERVER2 respectively).
Thanks,
Sanjiv
Thanks,
Sanjiv
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> On 6/19/06, James Strachan <ja...@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.
> >
> >
> > > This
> > > does not help with my use case where a message group represents a
> > > conversation and there can be several "conversations" taking place at
> > the
> > > same time.
> >
> > I should have been more clear... to clear message group FOO use
> >
> > message.setStringProperty("JMSXGroupID", "FOO");
> > message.setIntProperty("JMSXGroupSeq", 0);
>
>
> Who is the owner of the "JMSXGroupID" to broker mapping? Is it the JMS
> Connection or a JMSSession? I need to send messages by different Message
> Groups from the same client application. I would like to understand if I
> need to create separate JMS Connections for each message group based
> conversation, or separate JMS Sessions would suffice. A quick look at the
> source seems to indicate that Message Groups are held at the JMS connection
> level (ActiveMQConnectionMetaData). Can you confirm?
A broker manages Message Groups for its consumers. Its nothing to do
with connections per se - its purely a mapping of JMSXGroupID to
message consumer in a broker.
> It would also be great if you could explain the logic used to determine the
> recipient broker when a message is send using a message group in a "network
> of brokers" configuration.
the consumers on a remote broker are treated as normal consumers WRT
Message Groups.
> Is is that all brokers are aware of the message
> group -> recipient broker mapping and when a message is received by a broker
> in the network, it looks up the owning broker and appropriately redirects if
> required?
No - currently the mapping of Message Group ID -> consumer is private
to a broker.
--
James
-------
http://radio.weblogs.com/0112098/
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/19/06, James Strachan <ja...@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.
>
>
> > This
> > does not help with my use case where a message group represents a
> > conversation and there can be several "conversations" taking place at
> the
> > same time.
>
> I should have been more clear... to clear message group FOO use
>
> message.setStringProperty("JMSXGroupID", "FOO");
> message.setIntProperty("JMSXGroupSeq", 0);
Who is the owner of the "JMSXGroupID" to broker mapping? Is it the JMS
Connection or a JMSSession? I need to send messages by different Message
Groups from the same client application. I would like to understand if I
need to create separate JMS Connections for each message group based
conversation, or separate JMS Sessions would suffice. A quick look at the
source seems to indicate that Message Groups are held at the JMS connection
level (ActiveMQConnectionMetaData). Can you confirm?
It would also be great if you could explain the logic used to determine the
recipient broker when a message is send using a message group in a "network
of brokers" configuration. Is is that all brokers are aware of the message
group -> recipient broker mapping and when a message is received by a broker
in the network, it looks up the owning broker and appropriately redirects if
required?
Thanks,
Sanjiv
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> >
> > On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > The Message Group functionality of Active MQ 4.0 is really neat. I have
> > a
> > > couple of questions regarding this
> > >
> > > 1. Is this feature fully supported/tested with the P2P discovery style
> > > broker topology? Are they any test cases or samples I can try. I looked
> > for
> > > them in the source but wasn't able to locate them. And when I tried
> > running
> > > such a scenario, I did not see a proper load balancing (even round robin
> > > style) of message groups across available brokers. When messages
> > belonging
> > > to different message groups are sent, oftentimes only one or a small
> > > percentage of running brokers are chosen as recipients. As a result I
> > end up
> > > with some brokers that are overloaded while others are sitting idle.
> >
> > Generally Message Groups only apply to the broker which you are using;
> > there is no global cross-broker load balancing. So its intended when
> > using a traditional client-broker topology rather than a peer based
> > network.
> >
> > Though I'm surprised that you are finding on a single broker it is not
> > load balancing requests across multiple brokers. Are you sure there
> > are suitable consumers on those brokers?
>
>
> Consider a scenario where there are two servers, each of which have an
> embedded broker. What I'm seeing is that when clients send messages using
> Message Groups "MG1", "MG2", "MG3" and "MG4" etc, the messages with these
> different message groups aren't load balanced as expected. For example, MG1
> and MG2 (and sometimes even MG3) might be received by SERVER1. I was
> expected MG1 to go to SERVER1, MG2 to SERVER2, MG3 to SERVER1, MG4 to
> SERVER2 and so on.. The sample app that I uploaded with issue AMQ-760
> demonstrates this. Is this the expected behaviour? What is the message group
> based load balancing algorithm used?
The current algorithm is to lazily assign messages to groups when a
consumer is capable of receiving them. So its not a simple round
robin.
> > 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.
> This
> does not help with my use case where a message group represents a
> conversation and there can be several "conversations" taking place at the
> same time.
I should have been more clear... to clear message group FOO use
message.setStringProperty("JMSXGroupID", "FOO");
message.setIntProperty("JMSXGroupSeq", 0);
--
James
-------
http://radio.weblogs.com/0112098/
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
Hi,
I setup a network of three multicast based brokers on my machine. The server
app embeds each of these brokers. The client issues a command with a message
group as an argument. I made requests to 11 message groups ("A", "B", ....
"K") and as you can see from the screenshot below, message group "E" when to
broker1, message group "K" when to broker2, while all the other 9 message
groups when to broker3. (I even sent like 30 messages and the distribution
was broker1 = 2 messages, broker2=3 messages, broker3=25 messages)
http://www.jroller.com/resources/s/sjivan/lingo-mg.jpg
As suggested, I tried setting the consumer's destination queue prefetch to 1
(using url the option "?consumer.prefetch=1"), but the result was the same.
Consumer queu priority (using ?consumer.prority=10) also did not seem to
affect the load distribution across message groups.
My test client allows you to send requests specifying the message group from
a DOS shell. I do see the correct sticky and failover behaviour when I send
another message to message group "A" thorugh "K".
If you're interested in taking a look at this yourself, I have the source as
a maven project with the required statup bat files so it should be easy to
replicate the issue.
Thanks,
Sanjiv
On 6/19/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > >
> > > On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > > The Message Group functionality of Active MQ 4.0 is really neat. I
> have
> > > a
> > > > couple of questions regarding this
> > > >
> > > > 1. Is this feature fully supported/tested with the P2P discovery
> style
> > > > broker topology? Are they any test cases or samples I can try. I
> looked
> > > for
> > > > them in the source but wasn't able to locate them. And when I tried
> > > running
> > > > such a scenario, I did not see a proper load balancing (even round
> robin
> > > > style) of message groups across available brokers. When messages
> > > belonging
> > > > to different message groups are sent, oftentimes only one or a small
> > > > percentage of running brokers are chosen as recipients. As a result
> I
> > > end up
> > > > with some brokers that are overloaded while others are sitting idle.
> > >
> > > Generally Message Groups only apply to the broker which you are using;
> > > there is no global cross-broker load balancing. So its intended when
> > > using a traditional client-broker topology rather than a peer based
> > > network.
> > >
> > > Though I'm surprised that you are finding on a single broker it is not
> > > load balancing requests across multiple brokers. Are you sure there
> > > are suitable consumers on those brokers?
> >
> >
> > Consider a scenario where there are two servers, each of which have an
> > embedded broker. What I'm seeing is that when clients send messages
> using
> > Message Groups "MG1", "MG2", "MG3" and "MG4" etc, the messages with
> these
> > different message groups aren't load balanced as expected. For example,
> MG1
> > and MG2 (and sometimes even MG3) might be received by SERVER1. I was
> > expected MG1 to go to SERVER1, MG2 to SERVER2, MG3 to SERVER1, MG4 to
> > SERVER2 and so on.. The sample app that I uploaded with issue AMQ-760
> > demonstrates this. Is this the expected behaviour? What is the message
> group
> > based load balancing algorithm used?
>
> This is a bit complex. So the first message in a group chooses who
> the owner for the group is and that algorithm is the same that we use
> in normal queue message dispatching. So, it's round robin until a
> consumer's pre-fetch is full, and then he gets skipped. The complex
> bit is that we don't keep a separate round robin list for message
> groups, we are using the same round robin list that's used during
> normal message dispatching. And ownership of messages is tied to
> order of dispatching.
>
> So you can a a situations where if I have 3 consumers and then have
> the following order of sends:
> 1) send message 1, group 1 -> dispatch to consumer 1 first, it obtains
> ownership of message and group
> 2) send message 2, group 1 -> dispatch to consumer 2 first, but
> consumer retains ownership since it's in a group that it owns.
> 3) send message 3, without a group -> dispatch to consumer 3 first,
> and that consumer gets ownership of the message
> 4) send message 1, group2 -> dispatch to consumer 1 first, it obtains
> ownership of message and group.
>
> So.. I guess you can see now who message groups could protentialy get
> unbalanced if the right sequence of messages come in.
>
> >
> > > 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? This
> > does not help with my use case where a message group represents a
> > conversation and there can be several "conversations" taking place at
> the
> > same time. I would like the ability to end conversations on a per
> message
> > group basis and not globally. For example messages from MG1 might be
> > directed to SERVER1 and MG2 to SERVER2. After a sequence of operations,
> I
> > would like to end the conversation for MG1 but do not want to end the
> > conversation for MG2 and this might result in some MG2 messages going to
> > SERVER1 which has no knowledge of MG2's prior conversation.
> >
> >
> > Thanks,
> > Sanjiv
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
How does a Consumer Priority affect the message group load balancing
algorithm? The the message group load balancing algorithm take into
consideration the consumer priority?
Thanks,
Sanjiv
On 6/19/06, James Strachan <ja...@gmail.com> wrote:
>
> BTW if you configure a small prefetch value - or use a large number of
> message group values, you'll probably have fairer load balancing...
>
> http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html
>
>
> On 6/19/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > > >
> > > > On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > > > The Message Group functionality of Active MQ 4.0 is really neat. I
> have
> > > > a
> > > > > couple of questions regarding this
> > > > >
> > > > > 1. Is this feature fully supported/tested with the P2P discovery
> style
> > > > > broker topology? Are they any test cases or samples I can try. I
> looked
> > > > for
> > > > > them in the source but wasn't able to locate them. And when I
> tried
> > > > running
> > > > > such a scenario, I did not see a proper load balancing (even round
> robin
> > > > > style) of message groups across available brokers. When messages
> > > > belonging
> > > > > to different message groups are sent, oftentimes only one or a
> small
> > > > > percentage of running brokers are chosen as recipients. As a
> result I
> > > > end up
> > > > > with some brokers that are overloaded while others are sitting
> idle.
> > > >
> > > > Generally Message Groups only apply to the broker which you are
> using;
> > > > there is no global cross-broker load balancing. So its intended when
> > > > using a traditional client-broker topology rather than a peer based
> > > > network.
> > > >
> > > > Though I'm surprised that you are finding on a single broker it is
> not
> > > > load balancing requests across multiple brokers. Are you sure there
> > > > are suitable consumers on those brokers?
> > >
> > >
> > > Consider a scenario where there are two servers, each of which have an
> > > embedded broker. What I'm seeing is that when clients send messages
> using
> > > Message Groups "MG1", "MG2", "MG3" and "MG4" etc, the messages with
> these
> > > different message groups aren't load balanced as expected. For
> example, MG1
> > > and MG2 (and sometimes even MG3) might be received by SERVER1. I was
> > > expected MG1 to go to SERVER1, MG2 to SERVER2, MG3 to SERVER1, MG4 to
> > > SERVER2 and so on.. The sample app that I uploaded with issue AMQ-760
> > > demonstrates this. Is this the expected behaviour? What is the message
> group
> > > based load balancing algorithm used?
> >
> > This is a bit complex. So the first message in a group chooses who
> > the owner for the group is and that algorithm is the same that we use
> > in normal queue message dispatching. So, it's round robin until a
> > consumer's pre-fetch is full, and then he gets skipped. The complex
> > bit is that we don't keep a separate round robin list for message
> > groups, we are using the same round robin list that's used during
> > normal message dispatching. And ownership of messages is tied to
> > order of dispatching.
> >
> > So you can a a situations where if I have 3 consumers and then have
> > the following order of sends:
> > 1) send message 1, group 1 -> dispatch to consumer 1 first, it obtains
> > ownership of message and group
> > 2) send message 2, group 1 -> dispatch to consumer 2 first, but
> > consumer retains ownership since it's in a group that it owns.
> > 3) send message 3, without a group -> dispatch to consumer 3 first,
> > and that consumer gets ownership of the message
> > 4) send message 1, group2 -> dispatch to consumer 1 first, it obtains
> > ownership of message and group.
> >
> > So.. I guess you can see now who message groups could protentialy get
> > unbalanced if the right sequence of messages come in.
> >
> > >
> > > > 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?
> This
> > > does not help with my use case where a message group represents a
> > > conversation and there can be several "conversations" taking place at
> the
> > > same time. I would like the ability to end conversations on a per
> message
> > > group basis and not globally. For example messages from MG1 might be
> > > directed to SERVER1 and MG2 to SERVER2. After a sequence of
> operations, I
> > > would like to end the conversation for MG1 but do not want to end the
> > > conversation for MG2 and this might result in some MG2 messages going
> to
> > > SERVER1 which has no knowledge of MG2's prior conversation.
> > >
> > >
> > > Thanks,
> > > Sanjiv
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
BTW if you configure a small prefetch value - or use a large number of
message group values, you'll probably have fairer load balancing...
http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html
On 6/19/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > >
> > > On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > > The Message Group functionality of Active MQ 4.0 is really neat. I have
> > > a
> > > > couple of questions regarding this
> > > >
> > > > 1. Is this feature fully supported/tested with the P2P discovery style
> > > > broker topology? Are they any test cases or samples I can try. I looked
> > > for
> > > > them in the source but wasn't able to locate them. And when I tried
> > > running
> > > > such a scenario, I did not see a proper load balancing (even round robin
> > > > style) of message groups across available brokers. When messages
> > > belonging
> > > > to different message groups are sent, oftentimes only one or a small
> > > > percentage of running brokers are chosen as recipients. As a result I
> > > end up
> > > > with some brokers that are overloaded while others are sitting idle.
> > >
> > > Generally Message Groups only apply to the broker which you are using;
> > > there is no global cross-broker load balancing. So its intended when
> > > using a traditional client-broker topology rather than a peer based
> > > network.
> > >
> > > Though I'm surprised that you are finding on a single broker it is not
> > > load balancing requests across multiple brokers. Are you sure there
> > > are suitable consumers on those brokers?
> >
> >
> > Consider a scenario where there are two servers, each of which have an
> > embedded broker. What I'm seeing is that when clients send messages using
> > Message Groups "MG1", "MG2", "MG3" and "MG4" etc, the messages with these
> > different message groups aren't load balanced as expected. For example, MG1
> > and MG2 (and sometimes even MG3) might be received by SERVER1. I was
> > expected MG1 to go to SERVER1, MG2 to SERVER2, MG3 to SERVER1, MG4 to
> > SERVER2 and so on.. The sample app that I uploaded with issue AMQ-760
> > demonstrates this. Is this the expected behaviour? What is the message group
> > based load balancing algorithm used?
>
> This is a bit complex. So the first message in a group chooses who
> the owner for the group is and that algorithm is the same that we use
> in normal queue message dispatching. So, it's round robin until a
> consumer's pre-fetch is full, and then he gets skipped. The complex
> bit is that we don't keep a separate round robin list for message
> groups, we are using the same round robin list that's used during
> normal message dispatching. And ownership of messages is tied to
> order of dispatching.
>
> So you can a a situations where if I have 3 consumers and then have
> the following order of sends:
> 1) send message 1, group 1 -> dispatch to consumer 1 first, it obtains
> ownership of message and group
> 2) send message 2, group 1 -> dispatch to consumer 2 first, but
> consumer retains ownership since it's in a group that it owns.
> 3) send message 3, without a group -> dispatch to consumer 3 first,
> and that consumer gets ownership of the message
> 4) send message 1, group2 -> dispatch to consumer 1 first, it obtains
> ownership of message and group.
>
> So.. I guess you can see now who message groups could protentialy get
> unbalanced if the right sequence of messages come in.
>
> >
> > > 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? This
> > does not help with my use case where a message group represents a
> > conversation and there can be several "conversations" taking place at the
> > same time. I would like the ability to end conversations on a per message
> > group basis and not globally. For example messages from MG1 might be
> > directed to SERVER1 and MG2 to SERVER2. After a sequence of operations, I
> > would like to end the conversation for MG1 but do not want to end the
> > conversation for MG2 and this might result in some MG2 messages going to
> > SERVER1 which has no knowledge of MG2's prior conversation.
> >
> >
> > Thanks,
> > Sanjiv
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: detaching message group affinity
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 6/19/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> >
> > On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > The Message Group functionality of Active MQ 4.0 is really neat. I have
> > a
> > > couple of questions regarding this
> > >
> > > 1. Is this feature fully supported/tested with the P2P discovery style
> > > broker topology? Are they any test cases or samples I can try. I looked
> > for
> > > them in the source but wasn't able to locate them. And when I tried
> > running
> > > such a scenario, I did not see a proper load balancing (even round robin
> > > style) of message groups across available brokers. When messages
> > belonging
> > > to different message groups are sent, oftentimes only one or a small
> > > percentage of running brokers are chosen as recipients. As a result I
> > end up
> > > with some brokers that are overloaded while others are sitting idle.
> >
> > Generally Message Groups only apply to the broker which you are using;
> > there is no global cross-broker load balancing. So its intended when
> > using a traditional client-broker topology rather than a peer based
> > network.
> >
> > Though I'm surprised that you are finding on a single broker it is not
> > load balancing requests across multiple brokers. Are you sure there
> > are suitable consumers on those brokers?
>
>
> Consider a scenario where there are two servers, each of which have an
> embedded broker. What I'm seeing is that when clients send messages using
> Message Groups "MG1", "MG2", "MG3" and "MG4" etc, the messages with these
> different message groups aren't load balanced as expected. For example, MG1
> and MG2 (and sometimes even MG3) might be received by SERVER1. I was
> expected MG1 to go to SERVER1, MG2 to SERVER2, MG3 to SERVER1, MG4 to
> SERVER2 and so on.. The sample app that I uploaded with issue AMQ-760
> demonstrates this. Is this the expected behaviour? What is the message group
> based load balancing algorithm used?
This is a bit complex. So the first message in a group chooses who
the owner for the group is and that algorithm is the same that we use
in normal queue message dispatching. So, it's round robin until a
consumer's pre-fetch is full, and then he gets skipped. The complex
bit is that we don't keep a separate round robin list for message
groups, we are using the same round robin list that's used during
normal message dispatching. And ownership of messages is tied to
order of dispatching.
So you can a a situations where if I have 3 consumers and then have
the following order of sends:
1) send message 1, group 1 -> dispatch to consumer 1 first, it obtains
ownership of message and group
2) send message 2, group 1 -> dispatch to consumer 2 first, but
consumer retains ownership since it's in a group that it owns.
3) send message 3, without a group -> dispatch to consumer 3 first,
and that consumer gets ownership of the message
4) send message 1, group2 -> dispatch to consumer 1 first, it obtains
ownership of message and group.
So.. I guess you can see now who message groups could protentialy get
unbalanced if the right sequence of messages come in.
>
> > 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? This
> does not help with my use case where a message group represents a
> conversation and there can be several "conversations" taking place at the
> same time. I would like the ability to end conversations on a per message
> group basis and not globally. For example messages from MG1 might be
> directed to SERVER1 and MG2 to SERVER2. After a sequence of operations, I
> would like to end the conversation for MG1 but do not want to end the
> conversation for MG2 and this might result in some MG2 messages going to
> SERVER1 which has no knowledge of MG2's prior conversation.
>
>
> Thanks,
> Sanjiv
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: detaching message group affinity
Posted by Sanjiv Jivan <sa...@gmail.com>.
On 6/19/06, James Strachan <ja...@gmail.com> wrote:
>
> On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > The Message Group functionality of Active MQ 4.0 is really neat. I have
> a
> > couple of questions regarding this
> >
> > 1. Is this feature fully supported/tested with the P2P discovery style
> > broker topology? Are they any test cases or samples I can try. I looked
> for
> > them in the source but wasn't able to locate them. And when I tried
> running
> > such a scenario, I did not see a proper load balancing (even round robin
> > style) of message groups across available brokers. When messages
> belonging
> > to different message groups are sent, oftentimes only one or a small
> > percentage of running brokers are chosen as recipients. As a result I
> end up
> > with some brokers that are overloaded while others are sitting idle.
>
> Generally Message Groups only apply to the broker which you are using;
> there is no global cross-broker load balancing. So its intended when
> using a traditional client-broker topology rather than a peer based
> network.
>
> Though I'm surprised that you are finding on a single broker it is not
> load balancing requests across multiple brokers. Are you sure there
> are suitable consumers on those brokers?
Consider a scenario where there are two servers, each of which have an
embedded broker. What I'm seeing is that when clients send messages using
Message Groups "MG1", "MG2", "MG3" and "MG4" etc, the messages with these
different message groups aren't load balanced as expected. For example, MG1
and MG2 (and sometimes even MG3) might be received by SERVER1. I was
expected MG1 to go to SERVER1, MG2 to SERVER2, MG3 to SERVER1, MG4 to
SERVER2 and so on.. The sample app that I uploaded with issue AMQ-760
demonstrates this. Is this the expected behaviour? What is the message group
based load balancing algorithm used?
> 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? This
does not help with my use case where a message group represents a
conversation and there can be several "conversations" taking place at the
same time. I would like the ability to end conversations on a per message
group basis and not globally. For example messages from MG1 might be
directed to SERVER1 and MG2 to SERVER2. After a sequence of operations, I
would like to end the conversation for MG1 but do not want to end the
conversation for MG2 and this might result in some MG2 messages going to
SERVER1 which has no knowledge of MG2's prior conversation.
Thanks,
Sanjiv
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
On 6/19/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > The Message Group functionality of Active MQ 4.0 is really neat. I have a
> > > couple of questions regarding this
> > >
> > > 1. Is this feature fully supported/tested with the P2P discovery style
> > > broker topology? Are they any test cases or samples I can try. I looked for
> > > them in the source but wasn't able to locate them. And when I tried running
> > > such a scenario, I did not see a proper load balancing (even round robin
> > > style) of message groups across available brokers. When messages belonging
> > > to different message groups are sent, oftentimes only one or a small
> > > percentage of running brokers are chosen as recipients. As a result I end up
> > > with some brokers that are overloaded while others are sitting idle.
> >
> > Generally Message Groups only apply to the broker which you are using;
> > there is no global cross-broker load balancing. So its intended when
> > using a traditional client-broker topology rather than a peer based
> > network.
> >
> > Though I'm surprised that you are finding on a single broker it is not
> > load balancing requests across multiple brokers. Are you sure there
> > are suitable consumers on those brokers?
> >
>
> I don't think our brokers differentiate between a local consumer and a
> remote consumer accessed via a network. The broker could pick a
> remote consumer as the 'owner' of a group and all subsequent messages
> with that group id go to that remote broker. And then the remote
> broker gets the message and would actually pick a different local
> 'owner'
>
> So, yeah I could see how load balancing might not work correctly.
> This coupled with the fact that if there are multiple producers
> attached to different brokers, then each producers broker may elect a
> different 'owner' for the group which does not help matters at all.
>
> It would have been idea if either 1) a single consumer is picked to be
> the 'owner' across the whole broker network or 2) there is a consumer
> owner per broker and messages are balanced across all the brokers. I
> think #1 is the better option since it would allow for sequential
> processing of messages on a single node.
>
> Any ideas on how to fix this? Perhaps by employing some kind of broker advisory?
Another option is to have destinations owned by a specific broker so
that if a message is sent to a queue on a broker which is not the
owner, it sends the message to the 'owner broker' and it then does the
message-group processing..
Its a little like the Message Group concept but at the broker level
rather than the consumer level; let 1 broker be the 'controller' of a
given destination and let it choose the message group processing. This
can be useful for ensuring total ordering of messages on topics across
networks too (which is handy for distributed caching with optimistic
transactions).
--
James
-------
http://radio.weblogs.com/0112098/
Re: detaching message group affinity
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 6/19/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> > On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > > The Message Group functionality of Active MQ 4.0 is really neat. I have a
> > > couple of questions regarding this
> > >
> > > 1. Is this feature fully supported/tested with the P2P discovery style
> > > broker topology? Are they any test cases or samples I can try. I looked for
> > > them in the source but wasn't able to locate them. And when I tried running
> > > such a scenario, I did not see a proper load balancing (even round robin
> > > style) of message groups across available brokers. When messages belonging
> > > to different message groups are sent, oftentimes only one or a small
> > > percentage of running brokers are chosen as recipients. As a result I end up
> > > with some brokers that are overloaded while others are sitting idle.
> >
> > Generally Message Groups only apply to the broker which you are using;
> > there is no global cross-broker load balancing. So its intended when
> > using a traditional client-broker topology rather than a peer based
> > network.
> >
> > Though I'm surprised that you are finding on a single broker it is not
> > load balancing requests across multiple brokers. Are you sure there
> > are suitable consumers on those brokers?
> >
>
> I don't think our brokers differentiate between a local consumer and a
> remote consumer accessed via a network. The broker could pick a
> remote consumer as the 'owner' of a group and all subsequent messages
> with that group id go to that remote broker. And then the remote
> broker gets the message and would actually pick a different local
> 'owner'
>
> So, yeah I could see how load balancing might not work correctly.
> This coupled with the fact that if there are multiple producers
> attached to different brokers, then each producers broker may elect a
> different 'owner' for the group which does not help matters at all.
BTW: this would only be an issue when producers on different brokers
are sending to the same message group which might not be a common use
case.
>
> It would have been idea if either 1) a single consumer is picked to be
> the 'owner' across the whole broker network or 2) there is a consumer
> owner per broker and messages are balanced across all the brokers. I
> think #1 is the better option since it would allow for sequential
> processing of messages on a single node.
>
> Any ideas on how to fix this? Perhaps by employing some kind of broker advisory?
>
> >
> > > 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);
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: detaching message group affinity
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 6/19/06, James Strachan <ja...@gmail.com> wrote:
> On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> > The Message Group functionality of Active MQ 4.0 is really neat. I have a
> > couple of questions regarding this
> >
> > 1. Is this feature fully supported/tested with the P2P discovery style
> > broker topology? Are they any test cases or samples I can try. I looked for
> > them in the source but wasn't able to locate them. And when I tried running
> > such a scenario, I did not see a proper load balancing (even round robin
> > style) of message groups across available brokers. When messages belonging
> > to different message groups are sent, oftentimes only one or a small
> > percentage of running brokers are chosen as recipients. As a result I end up
> > with some brokers that are overloaded while others are sitting idle.
>
> Generally Message Groups only apply to the broker which you are using;
> there is no global cross-broker load balancing. So its intended when
> using a traditional client-broker topology rather than a peer based
> network.
>
> Though I'm surprised that you are finding on a single broker it is not
> load balancing requests across multiple brokers. Are you sure there
> are suitable consumers on those brokers?
>
I don't think our brokers differentiate between a local consumer and a
remote consumer accessed via a network. The broker could pick a
remote consumer as the 'owner' of a group and all subsequent messages
with that group id go to that remote broker. And then the remote
broker gets the message and would actually pick a different local
'owner'
So, yeah I could see how load balancing might not work correctly.
This coupled with the fact that if there are multiple producers
attached to different brokers, then each producers broker may elect a
different 'owner' for the group which does not help matters at all.
It would have been idea if either 1) a single consumer is picked to be
the 'owner' across the whole broker network or 2) there is a consumer
owner per broker and messages are balanced across all the brokers. I
think #1 is the better option since it would allow for sequential
processing of messages on a single node.
Any ideas on how to fix this? Perhaps by employing some kind of broker advisory?
>
> > 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);
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: detaching message group affinity
Posted by James Strachan <ja...@gmail.com>.
On 6/17/06, Sanjiv Jivan <sa...@gmail.com> wrote:
> The Message Group functionality of Active MQ 4.0 is really neat. I have a
> couple of questions regarding this
>
> 1. Is this feature fully supported/tested with the P2P discovery style
> broker topology? Are they any test cases or samples I can try. I looked for
> them in the source but wasn't able to locate them. And when I tried running
> such a scenario, I did not see a proper load balancing (even round robin
> style) of message groups across available brokers. When messages belonging
> to different message groups are sent, oftentimes only one or a small
> percentage of running brokers are chosen as recipients. As a result I end up
> with some brokers that are overloaded while others are sitting idle.
Generally Message Groups only apply to the broker which you are using;
there is no global cross-broker load balancing. So its intended when
using a traditional client-broker topology rather than a peer based
network.
Though I'm surprised that you are finding on a single broker it is not
load balancing requests across multiple brokers. Are you sure there
are suitable consumers on those brokers?
> 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);
--
James
-------
http://radio.weblogs.com/0112098/