Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of martinc@gmx.at designates
 213.165.64.23 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BANLkTimgvFJqrqq0LsQEioBwp3_aOqS8JA@mail.gmail.com>
References: <BANLkTi=mPH-6S4OTXVpwq5kJEVSH3xunXg@mail.gmail.com>
 <1309494093071-3637432.post@n4.nabble.com>
 <BANLkTinq2VUGV+NEL6LAopQqpp9xH1m9Pw@mail.gmail.com>
 <BANLkTimgvFJqrqq0LsQEioBwp3_aOqS8JA@mail.gmail.com>
From: "Martin C." <martinc@gmx.at>
Date: Sat, 2 Jul 2011 14:54:01 +0200
Message-ID: 
 <CANy=r+xz3ObjZP7KTqOBWJ6ayXwmr1hgzTgDZg=ZcLHUtUiOAA@mail.gmail.com>
Subject: Re: Fwd: Message groups enhancement feature request
To: users@activemq.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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