On 25 March 2016 at 19:06, Garlapati Sreeram Kumar <sreer...@live.com> wrote: > Hello All! > > We are using the Proton-J 0.12.0 Amqp library – and built Event Hubs Java > Amqp Client on Reactor framework - > https://github.com/Azure/azure-event-hubs/tree/master/java. > > Please validate my assumption w.r.to Sender Flow control: > - Current Expectation from Reactor APIs is that – on Sender Link – wait for > the onLinkFlow(Event) and rely on > “event.getLInk().getRemoteCredit()” > to know how many more messages can be Sent on the Link. Proton amqp layer > will interpret the FlowFrame and do-the-math of deliveryCounts of Sender and > Receiver and the New Credit issued by the Sender. > - This API Contract essentially means that, Frameworks building atop Reactor > API – will need to implement FlowControl (will queue-up all the Messages > until it receives the FlowFrame). > > Do you folks have plans to move this functionality of flow control into the > Proton-API offering – as every implementation will need it. > > Thanks! > Sree > >
Hi Sree, The above seems essentially correct yes. The sender/engine can actually buffer messages beyond that which it has credit to send and then send them later (if credit ever arrives), but I'm not sure how much you would typically want to take advantage of that, versus prefering some sort of application/client-level handling that can be made to suit your particular needs w.r.t any buffering / pausing of message sources / blocking etc you might want to do. Robbie