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:[email protected]
