On 07/05/2013 03:25 PM, Rob Godfrey wrote:
It depends on what you mean by "works", but I believe message flow should be able to be used (note destination is optional),
Ah, so it is! I confess I never noticed that.
however obviously the granularity is flow controlling the entire session
That's not explicitly stated, and given the 'blank-destination' rule for transfer one could perhaps be forgiven for thinking that if not specified the default exchange was implied. (Of course blank is not null I hear you all cry!)
The other problem is that none of the clients expected to need to wait for session level credit (and at least one of them was written by a spec author ;-)
I suppose you could have had the server immediately send a message-stop as soon as the session was attached. I guess in this guise it is somewhat similar to the old 0-8/0-9 style flow control, but that too has its issues.
When implementing flow control in 0-10 in the Java broker this is what I initially implemented, only to find that the JMS client had been designed to "work" with the delayed completions scheme.
Actually I think the point is it wasn't designed to work with delayed completions. In fact none of the clients were designed were.
The current approach to flow control in the c++ broker was based on the observation that most (all?) 0-10 clients already implemented some form of in-doubt buffer (for replay purposes) and that delaying completions would almost transparently have the effect of throttling senders. This is certainly a best effort scheme for managing temporary imbalance in rates; a pragmatic workaround pending a more complete and correct solution.
I think it would work for JMS as well (the python client also has a timeout for syncing). I suspect the issue is down to incorrect assumptions regarding message-flush.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
