qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: credit window sizing behaviour
Date Thu, 17 Nov 2011 19:21:59 GMT
On 17 November 2011 16:03, Gordon Sim <gsim@redhat.com> wrote:
> On 11/17/2011 02:52 PM, Robbie Gemmell wrote:
>> Keith and I noticed some behavioural difference between the Java and
>> C++ broker with regards to credit window sizing, whilst investigating
>> QPID-2703. As per QPID-3629, it appears that the C++ broker will
>> effectively allow clients to expand the credit window beyond the
>> limits specified by the previous message.flow command under certain
>> circumstances.
>> For example:
>> 1) Send 11 messages.
>> 2) Issue message flow with unlimited bytes and 5 message credits.
>> 3) Receive 5 messages.
>> 4) Issue a message.stop.
>> 5) Issue message flow with unlimited bytes and 5 message credits.
>> 6) Complete the commands for messages received earlier.
>> In this scenario we would expect the client to only ever be allowed to
>> have 5 uncompleted messages, because the credit limit has never been
>> set to anything except 0 or 5, and this is the behaviour the Java
>> broker exhibits. The C++ broker treats this situation differently
>> though and upon the client sending completions for the earlier
>> messages it expands the window to 10 messages, allowing the client to
>> have more messages than it requested.
> I think the C++ broker is wrong there; it doesn't take account of
> uncompleted messages still outstanding when the stop is issued.

Looking at the trace logging, it appeared that the C++ broker uses 1
value each to track the available bytes/message credit. The Java
broker handled this differently because it uses two values for each,
one for the current 'credit limit' based on message.flow/message.stop
commands sent and another for the current amount of  'used credit'
which gets manipulated by requesting to use credit or restoring it via
completions, with the 'available credit' being a decision based on
those values. There are certainly other ways to handle it similarly

>> An additional difference in behaviour noticed was that in the above
>> scenario, the Java broker will not send any more messages until the
>> completions are issued for the 5 messages the client already had
>> originally, whereas the C++ broker starts sending more messages as
>> soon as the second message.flow command is sent, despite the
>> outstanding messages. This too allows the client to have more
>> outstanding messages than the specified window would seem to allow.
> This is perhaps less obvious (the spec is light on detail), but I think the
> Java brokers behaviour seems preferable. I would be in favour of fixing the
> C++ broker to do the same thing.

Agreed, the spec doesnt really properly define what happens there, but
I also thought the Java brokers behaviour was preferable.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message