BTW. we have open feature request for the broker rebalance message groups when consumers are added/removed ( https://issues.apache.org/jira/browse/AMQ-2106). I think that's the best way to handle this use case. In any case, any contribution in this area is welcomed.
Regards -- Dejan Bosanac - http://twitter.com/dejanb ----------------- The experts in open source integration and messaging - http://fusesource.com ActiveMQ in Action - http://www.manning.com/snyder/ Blog - http://www.nighttale.net On Sat, Jul 2, 2011 at 2:54 PM, Martin C. <[email protected]> wrote: > Hi, > > > So it sounds like the current Message Groups behaviour is fine; its > > just you want to ensure fair load balancing of the message groups > > across consumers right? So if lots of other clients are restarted; the > > long running clients could end up claiming too many of the message > > groups? > > Yes, you absolutely got it right. The current behavior is absolutely > correct and well-defined and within the specs of JMS as far as I know > it. That's why I call my idea an "enhancement", because I think it > could aid i some situations to provide better scalability. > > > I wonder if just recycling consumers every now and again would do the > > trick? i.e. a pure client side thing to terminate a consumer every now > > and again to force rebalancing of message groups? > > This is a very valid approach and one I am currently implementing for > the Spring MessageListenerContainer setup we have. But it has some > side-effects: this generates advisory messages which will be > distributed throughout the network of brokers, if > dynamicallyIncludedDestinations are involved and in huge > network-of-brokers, those advisories (in our case) can make up most of > the WAN network traffic. That's why I want to keep them down. > > I am not sure if it can be handled by the MessageConsumer alone or if > a feature like this would be better implemented on the broker side, > but my "dream" solution would be > session.createConsumer("queue.foo?releaseMessageGroupsAfter=1") > telling the broker that he can freely re-distribute the message group > like seems best after the current message has been ACKed. > > Thanks for any input. > > Best regards, > Martin >
