RE: Proton-j: SendLink flow control

2016-03-30 Thread Garlapati Sreeram Kumar
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 <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


Re: Proton-j: SendLink flow control

2016-03-30 Thread Robbie Gemmell
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