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? Robbie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
