On 17 November 2011 16:03, Gordon Sim <[email protected]> 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:[email protected]
