On Mon, Oct 31, 2011 at 11:30 AM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > It doesnt really affect that case at all I think. It only affects > transacted sessions and although it does slightly move the location of > a call also made for synchronous consumers, the effect of the change > only really makes any difference to asynchronous consumers.
I'm fine with the current change you've made. Lets actually look at this credit issue in more detail after the release. > Robbie > > On 31 October 2011 15:19, Rajith Attapattu <rajit...@gmail.com> wrote: >> On Mon, Oct 31, 2011 at 9:18 AM, Robbie Gemmell >> <robbie.gemm...@gmail.com> wrote: >>> Hi all, >>> >>> Over the weekend I made a change to the 0-10 Java client so that using >>> prefetch=1 with transacted sessions and an OnMessage() listener would >>> result in the client only getting 1 message at a time, by moving the >>> sending of command completions (if necessary) which would prompt the >>> next message into postDeliver() instead of doing it before delivery. >>> This was in response to a user on the mailing lists trying to >>> configure the client such that when an extra long period of processing >>> occurred in his listener, other clients would be able to pick up the >>> rest of the messages on the queue. However, whilst this behaviour is >>> what the 0-8 client does in this case, after making the change I >>> decided this is really prefetch=0 (which is something the 0-8 client >>> doesn't support) behaviour for the 0-10 client. >>> >>> The same user had it turns out also tried prefetch=0 and found it to >>> behave rather oddly, almost like prefetch=2. Deciding that I should >>> perhaps instead revert the change I made and look at fixing >>> prefetch=0, I had a quick play with it to see what it did and found it >>> to behave similarly to his observations. Looking at the code, prefetch >>> of 0 appears to be horribly broken for an asynchronous message >>> listener in its current form, and will indeed act more like >>> prefetch=2. It appears that message credit is sent when the connection >>> is started, and when a message listener is set (seemingly regardless >>> of whether the connection is started, which would itself be a bug if >>> true), meaning more than 1 credit can be issued for something that >>> should have at most 1 message at a time. Regardless of this, >>> prefetch=0 wont work for a message listener because the client also >>> then sends a credit to provoke the next delivery just *before* passing >>> of the message to the application instead of afterwards like it >>> should. >>> >>> The change I made previously was very small (same code, called in a >>> different place) and doesn't really make any difference to synchronous >>> consumers because the completions are still sent before the >>> application gets the message. It only really affects asynchronous >>> transacted consumers with a prefetch of 1 configured, and gives them >>> the ability to achieve the desired behaviour, but at the expense of >>> effectively being out-by-1 on the count. The changes to get prefetch=0 >>> working for such cases could be larger, and I probably wont get time >>> to look at doing that for this release either way. >>> >>> So the question is, keep the current change in to provide a means of >>> users getting the client to do what they want right now, or revert it >>> and fix prefetch=0 later? I'd say keep it, what do the rest of you >>> think? >> >> This is infact an issue that we had identified (in the context of the >> JCA client) and was aiming to fix soon after the release. >> I'd argue that the logic around credits are broken in general - QPID-2604. >> I haven't really looked at your change closely. Not sure how it >> affects the above case. >> >>> Robbie >>> >>> --------------------------------------------------------------------- >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:dev-subscr...@qpid.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> >> > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
