You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2011/11/17 15:52:17 UTC
credit window sizing behaviour
Hi all,
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.
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.
It would be good to agree on what the expected behaviour for window
credit actually is so that users get a consistent experience across
both brokers.
Regards,
Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: credit window sizing behaviour
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 November 2011 16:03, Gordon Sim <gs...@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
though.
>> 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.
Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: credit window sizing behaviour
Posted by Gordon Sim <gs...@redhat.com>.
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