On 5 July 2013 18:01, Gordon Sim <[email protected]> wrote: > 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. > >
Yeah - one could also set the destination and have per exchange flow control of course :-). > 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. > > > Yes... there is clearly a bug in the JMS client if it is using flush, not sync... however if the broker does enforce flow control then the client cannot differentiate between being flow controlled and a broker side issue. In the 0-9 implementation we use basic qos to flow control the session, and a different timeout / log message is generated. Moreover there is then no doubt as to whether the message has actually made it to the broker or not as the control is enforced "before" sending. However, all this being said... the answer is clearly just to move to using AMQP 1.0 as soon as possible :-) -- Rob > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
