RE: Proton-j: SendLink flow control
Thanks a lot Robbie. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com> Sent: Wednesday, March 30, 2016 2:27 AM To: proton@qpid.apache.org<mailto:proton@qpid.apache.org> Subject: Re: Proton-j: SendLink flow control On 25 March 2016 at 19:06, Garlapati Sreeram Kumar 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
Re: Proton-j: SendLink flow control
On 25 March 2016 at 19:06, Garlapati Sreeram Kumar 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
Proton-j: SendLink flow control
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