qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: credit window sizing behaviour
Date Thu, 17 Nov 2011 16:03:27 GMT
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.

> 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.

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

View raw message