RE: Proton-j Reactor - Receiver

[Garlapati Sreeram Kumar]

Hello Robbie – That’s correct, please go ahead with the release 0.12.2.
As per your suggestion, I will follow up on this issue with a Simple reproducer.

Thx!
Sree

From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
Sent: Friday, April 15, 2016 7:09 AM
To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
hm...@microsoft.com<mailto:hm...@microsoft.com>
Subject: Re: Proton-j Reactor - Receiver

Hi Sree,

Your attachment didnt make it, the mailing list strips almost all
attachments, particularly of any non trivial size. Best to attach
stuff to JIRAs or provide links to them elsewhere.

I had another look at it and still don't see a way for it to do what
it did before, I'd guess it may be something slightly different. I
think I'll need more analysis and/or a reproducer from you to make any
further progress.

0.12.2 currently has the votes to pass. If it stays that way I
probably lean towards proceeding with its release unless more concrete
details becomes obvious, since it does seem to give a good improvement
over the previous behaviour.

Robbie

On 15 April 2016 at 01:35, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
> Hello Robbie,
>
>
>
> After couple hours of Stress Run with the proton-j change – we still could
> repro the Receive Stuck problem. Although – the below bug fix places us in a
> much better state now.
>
> Attached a screenshot of Objects sizes on Heap – which corresponds to the
> codepath that you fixed (SimpleSslTransportWrapper).
>
> Please see if this rings any bells – I am more than happy to share more
> details (proton traces & dump – pls suggest if you will need more details).
>
>
>
> Thx!
>
> Sree
>
>
>
> From: Garlapati Sreeram Kumar
> Sent: Monday, April 11, 2016 11:50 AM
> To: Robbie Gemmell; proton@qpid.apache.org
> Cc: SeongJoon Kwak (SJ); hm...@microsoft.com
> Subject: RE: Proton-j Reactor - Receiver
>
>
>
> Awesome.
>
> To make it easy - added you as collaborator to my fork of Proton & here’s
> the branch from which I submitted the PR:
> https://github.com/SreeramGarlapati/qpid-proton/tree/sg.recvstuck
>
> Thx!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Monday, April 11, 2016 9:52 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>;
> hm...@microsoft.com<mailto:hm...@microsoft.com>
> Subject: Re: Proton-j Reactor - Receiver
>
> Ah, excellent. I had actually started on testing this myself a little
> earlier, so I'll take a look and see whats what before continuing
> tomorrow. On taking an initial better look at things I think the
> change itself may need augmented to account for some other conditions
> too, need to investigate further to be sure.
>
> Robbie
>
> On 11 April 2016 at 17:37, Garlapati Sreeram Kumar <sreer...@live.com>
> wrote:
>> Thanks a lot for the Response Robbie!
>> Per your suggestion, added the CIT to the Pull Request (& yes, as you
>> already said – this issue is being tracked via JIRA - PROTON-1171).
>>
>> Thanks a lot for the Wonderful Collaboration!
>> Sree
>>
>> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
>> Sent: Thursday, April 7, 2016 3:52 AM
>> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
>> Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>;
>> hm...@microsoft.com<mailto:hm...@microsoft.com>
>> Subject: Re: Proton-j Reactor - Receiver
>>
>> Hi Sree,
>>
>> Thanks for the analysis and PR, I'll try to take a proper look soon.
>> It's not an area of the code I'm familiar with so I'll need to have a
>> bit of a dig myself to see if the change seems ok. I'd note that any
>> not-insignificant bug fix such as this should probably have a test
>> with it (and a JIRA, though I see you have since created one of those)
>> :)
>>
>> Robbie
>>
>> On 6 April 2016 at 01:23, Garlapati Sreeram Kumar <sreer...@live.com>
>> wrote:
>>> Hello Robbie,
>>>
>>> We are using proton-j client with SSL and many of our customers are
>>> hitting this issue.
>>> Here are my findings after debugging through this issue:
>>>
>>> -  When incoming bytes arrive on the SocketChannel – proton-j
>>> client gets signaled by nio & as a result it unwinds the transport stack –
>>> as a result all the TransportInput implementations performs its task on the
>>> Read Bytes and hands off to the Next Layer in the stack (transport to ssl,
>>> ssl to frameparser etc).
>>

RE: Proton-j Reactor - Receiver

[Garlapati Sreeram Kumar]

Hello Robbie,

After couple hours of Stress Run with the proton-j change – we still could 
repro the Receive Stuck problem. Although – the below bug fix places us in a 
much better state now.
Attached a screenshot of Objects sizes on Heap – which corresponds to the 
codepath that you fixed (SimpleSslTransportWrapper).
Please see if this rings any bells – I am more than happy to share more details 
(proton traces & dump – pls suggest if you will need more details).

Thx!
Sree

From: Garlapati Sreeram Kumar<mailto:sreer...@live.com>
Sent: Monday, April 11, 2016 11:50 AM
To: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>; 
proton@qpid.apache.org<mailto:proton@qpid.apache.org>
Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
hm...@microsoft.com<mailto:hm...@microsoft.com>
Subject: RE: Proton-j Reactor - Receiver

Awesome.

To make it easy - added you as collaborator to my fork of Proton & here’s the 
branch from which I submitted the PR: 
https://github.com/SreeramGarlapati/qpid-proton/tree/sg.recvstuck

Thx!
Sree

From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
Sent: Monday, April 11, 2016 9:52 AM
To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
hm...@microsoft.com<mailto:hm...@microsoft.com>
Subject: Re: Proton-j Reactor - Receiver

Ah, excellent. I had actually started on testing this myself a little
earlier, so I'll take a look and see whats what before continuing
tomorrow. On taking an initial better look at things I think the
change itself may need augmented to account for some other conditions
too, need to investigate further to be sure.

Robbie

On 11 April 2016 at 17:37, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
> Thanks a lot for the Response Robbie!
> Per your suggestion, added the CIT to the Pull Request (& yes, as you already 
> said – this issue is being tracked via JIRA - PROTON-1171).
>
> Thanks a lot for the Wonderful Collaboration!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Thursday, April 7, 2016 3:52 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
> hm...@microsoft.com<mailto:hm...@microsoft.com>
> Subject: Re: Proton-j Reactor - Receiver
>
> Hi Sree,
>
> Thanks for the analysis and PR, I'll try to take a proper look soon.
> It's not an area of the code I'm familiar with so I'll need to have a
> bit of a dig myself to see if the change seems ok. I'd note that any
> not-insignificant bug fix such as this should probably have a test
> with it (and a JIRA, though I see you have since created one of those)
> :)
>
> Robbie
>
> On 6 April 2016 at 01:23, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
>> Hello Robbie,
>>
>> We are using proton-j client with SSL and many of our customers are hitting 
>> this issue.
>> Here are my findings after debugging through this issue:
>>
>> -  When incoming bytes arrive on the SocketChannel – proton-j client 
>> gets signaled by nio & as a result it unwinds the transport stack – as a 
>> result all the TransportInput implementations performs its task on the Read 
>> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
>> frameparser etc).
>>
>> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
>> reads(16k bytes) from _inputBuffer and the result - decoded bytes are 
>> written to _decodedInputBuffer – as an intermediate buffer.
>>
>> -  It then flushes bytes from intermediate buffer to the next layer 
>> & invokes an _underlyingInput.Process() – to signal it that it has bytes in 
>> its input buffer.
>>
>> -  If the underlyingInput (lets say FrameParser) buffer size is 
>> small – lets say 4k – then decodedInputBuffer will be left with 12k bytes & 
>> Over time this accrues.
>>
>> The fix here is to flush decodedInputBuffer to the Next transport in the 
>> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer 
>> is empty. Here’s the pull request - 
>> https://github.com/apache/qpid-proton/pull/73
>>
>> Pl. let me know if we need to do more to fix this issue comprehensively.
>>
>> Thx!
>> Sree
>>
>> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
>> Sent: Thursday, March 31, 2016 9:19 AM
>> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
>> Subject: Re: Proton-j Reactor - Receiver
>>
>> On 31 March 2016 at 04:32, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
>>> Hello All!
>>>
&g

RE: Proton-j Reactor - Receiver

[Garlapati Sreeram Kumar]

Awesome.

To make it easy - added you as collaborator to my fork of Proton & here’s the 
branch from which I submitted the PR: 
https://github.com/SreeramGarlapati/qpid-proton/tree/sg.recvstuck

Thx!
Sree

From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
Sent: Monday, April 11, 2016 9:52 AM
To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
hm...@microsoft.com<mailto:hm...@microsoft.com>
Subject: Re: Proton-j Reactor - Receiver

Ah, excellent. I had actually started on testing this myself a little
earlier, so I'll take a look and see whats what before continuing
tomorrow. On taking an initial better look at things I think the
change itself may need augmented to account for some other conditions
too, need to investigate further to be sure.

Robbie

On 11 April 2016 at 17:37, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
> Thanks a lot for the Response Robbie!
> Per your suggestion, added the CIT to the Pull Request (& yes, as you already 
> said – this issue is being tracked via JIRA - PROTON-1171).
>
> Thanks a lot for the Wonderful Collaboration!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Thursday, April 7, 2016 3:52 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
> hm...@microsoft.com<mailto:hm...@microsoft.com>
> Subject: Re: Proton-j Reactor - Receiver
>
> Hi Sree,
>
> Thanks for the analysis and PR, I'll try to take a proper look soon.
> It's not an area of the code I'm familiar with so I'll need to have a
> bit of a dig myself to see if the change seems ok. I'd note that any
> not-insignificant bug fix such as this should probably have a test
> with it (and a JIRA, though I see you have since created one of those)
> :)
>
> Robbie
>
> On 6 April 2016 at 01:23, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
>> Hello Robbie,
>>
>> We are using proton-j client with SSL and many of our customers are hitting 
>> this issue.
>> Here are my findings after debugging through this issue:
>>
>> -  When incoming bytes arrive on the SocketChannel – proton-j client 
>> gets signaled by nio & as a result it unwinds the transport stack – as a 
>> result all the TransportInput implementations performs its task on the Read 
>> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
>> frameparser etc).
>>
>> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
>> reads(16k bytes) from _inputBuffer and the result - decoded bytes are 
>> written to _decodedInputBuffer – as an intermediate buffer.
>>
>> -  It then flushes bytes from intermediate buffer to the next layer 
>> & invokes an _underlyingInput.Process() – to signal it that it has bytes in 
>> its input buffer.
>>
>> -  If the underlyingInput (lets say FrameParser) buffer size is 
>> small – lets say 4k – then decodedInputBuffer will be left with 12k bytes & 
>> Over time this accrues.
>>
>> The fix here is to flush decodedInputBuffer to the Next transport in the 
>> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer 
>> is empty. Here’s the pull request - 
>> https://github.com/apache/qpid-proton/pull/73
>>
>> Pl. let me know if we need to do more to fix this issue comprehensively.
>>
>> Thx!
>> Sree
>>
>> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
>> Sent: Thursday, March 31, 2016 9:19 AM
>> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
>> Subject: Re: Proton-j Reactor - Receiver
>>
>> On 31 March 2016 at 04:32, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
>>> Hello All!
>>>
>>> I am using Proton-J reactor API (Version 0.12.0) for receiving AMQP 
>>> Messages (from Microsoft Azure Event Hubs): 
>>> https://github.com/Azure/azure-event-hubs/blob/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp/ReceiveLinkHandler.java#L124
>>>
>>> Am using the onDelivery(Event) callback to receive messages. I really 
>>> appreciate your help with this issue/behavior:
>>>
>>> ISSUE: I noticed that the last few messages on the Queue are not being 
>>> issued to onDelivery(Event) callback by the Reactor
>>> - Then, I went ahead and enabled proton Frame tracing (PN_TRACE_FRM=1) and 
>>> discovered that the Transfer frames corresponding to those messages were 
>>> not even delivered to Client. Then, I looked at our Service 

RE: Proton-j Reactor - Receiver

[Garlapati Sreeram Kumar]

Thanks a lot for the Response Robbie!
Per your suggestion, added the CIT to the Pull Request (& yes, as you already 
said – this issue is being tracked via JIRA - PROTON-1171).

Thanks a lot for the Wonderful Collaboration!
Sree

From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
Sent: Thursday, April 7, 2016 3:52 AM
To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
Cc: SeongJoon Kwak (SJ)<mailto:sjk...@microsoft.com>; 
hm...@microsoft.com<mailto:hm...@microsoft.com>
Subject: Re: Proton-j Reactor - Receiver

Hi Sree,

Thanks for the analysis and PR, I'll try to take a proper look soon.
It's not an area of the code I'm familiar with so I'll need to have a
bit of a dig myself to see if the change seems ok. I'd note that any
not-insignificant bug fix such as this should probably have a test
with it (and a JIRA, though I see you have since created one of those)
:)

Robbie

On 6 April 2016 at 01:23, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
> Hello Robbie,
>
> We are using proton-j client with SSL and many of our customers are hitting 
> this issue.
> Here are my findings after debugging through this issue:
>
> -  When incoming bytes arrive on the SocketChannel – proton-j client 
> gets signaled by nio & as a result it unwinds the transport stack – as a 
> result all the TransportInput implementations performs its task on the Read 
> Bytes and hands off to the Next Layer in the stack (transport to ssl, ssl to 
> frameparser etc).
>
> -  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
> reads(16k bytes) from _inputBuffer and the result - decoded bytes are written 
> to _decodedInputBuffer – as an intermediate buffer.
>
> -  It then flushes bytes from intermediate buffer to the next layer & 
> invokes an _underlyingInput.Process() – to signal it that it has bytes in its 
> input buffer.
>
> -  If the underlyingInput (lets say FrameParser) buffer size is small 
> – lets say 4k – then decodedInputBuffer will be left with 12k bytes & Over 
> time this accrues.
>
> The fix here is to flush decodedInputBuffer to the Next transport in the 
> Network Stack & call _underlyingInput.Process() - until decodedInputBuffer is 
> empty. Here’s the pull request - https://github.com/apache/qpid-proton/pull/73
>
> Pl. let me know if we need to do more to fix this issue comprehensively.
>
> Thx!
> Sree
>
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Thursday, March 31, 2016 9:19 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Subject: Re: Proton-j Reactor - Receiver
>
> On 31 March 2016 at 04:32, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
>> Hello All!
>>
>> I am using Proton-J reactor API (Version 0.12.0) for receiving AMQP Messages 
>> (from Microsoft Azure Event Hubs): 
>> https://github.com/Azure/azure-event-hubs/blob/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp/ReceiveLinkHandler.java#L124
>>
>> Am using the onDelivery(Event) callback to receive messages. I really 
>> appreciate your help with this issue/behavior:
>>
>> ISSUE: I noticed that the last few messages on the Queue are not being 
>> issued to onDelivery(Event) callback by the Reactor
>> - Then, I went ahead and enabled proton Frame tracing (PN_TRACE_FRM=1) and 
>> discovered that the Transfer frames corresponding to those messages were not 
>> even delivered to Client. Then, I looked at our Service Proton Frames and 
>> can clearly see that they are being delivered by the Service. And other AMQP 
>> clients (for ex: .net client can see the Transfer frames)
>> - Is this a known behavior?
>> Does Reactor code path disable Nagle on underlying socket – could this be 
>> related? or is there any other Configuration that we should be setting to 
>> see all Transfer frames received on the Socket?
>>
>> Please advice.
>>
>> Thanks a lot in Advance!
>> Sree
>>
>> Sent from Mail for Windows 10
>>
>
> I'm not aware of anyone else reporting anything like that. I don't see
> anything in the code suggesting the reactor sets TCP_NODELAY trueon
> the socket, but I wouldn't think that should matter here.
>
> The frame trace logging is done after the bytes are given to the
> Transport and are processed into frames, so a lack of logging could
> suggest various things such as they didnt actually get there, they
> werent processed, something went wrong before they did/were, something
> went wrong decoding them, etc. Its hard to say much more without more
> info.
>
> Robbie

RE: Proton-j Reactor - Receiver

[Garlapati Sreeram Kumar]

Hello Robbie,

We are using proton-j client with SSL and many of our customers are hitting 
this issue.
Here are my findings after debugging through this issue:

-  When incoming bytes arrive on the SocketChannel – proton-j client 
gets signaled by nio & as a result it unwinds the transport stack – as a result 
all the TransportInput implementations performs its task on the Read Bytes and 
hands off to the Next Layer in the stack (transport to ssl, ssl to frameparser 
etc).

-  While unwinding that stack, SimpleSSLTransportWrapper.unwrapInput 
reads(16k bytes) from _inputBuffer and the result - decoded bytes are written 
to _decodedInputBuffer – as an intermediate buffer.

-  It then flushes bytes from intermediate buffer to the next layer & 
invokes an _underlyingInput.Process() – to signal it that it has bytes in its 
input buffer.

-  If the underlyingInput (lets say FrameParser) buffer size is small – 
lets say 4k – then decodedInputBuffer will be left with 12k bytes & Over time 
this accrues.

The fix here is to flush decodedInputBuffer to the Next transport in the 
Network Stack & call _underlyingInput.Process() - until decodedInputBuffer is 
empty. Here’s the pull request - https://github.com/apache/qpid-proton/pull/73

Pl. let me know if we need to do more to fix this issue comprehensively.

Thx!
Sree

From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
Sent: Thursday, March 31, 2016 9:19 AM
To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
Subject: Re: Proton-j Reactor - Receiver

On 31 March 2016 at 04:32, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
> Hello All!
>
> I am using Proton-J reactor API (Version 0.12.0) for receiving AMQP Messages 
> (from Microsoft Azure Event Hubs): 
> https://github.com/Azure/azure-event-hubs/blob/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp/ReceiveLinkHandler.java#L124
>
> Am using the onDelivery(Event) callback to receive messages. I really 
> appreciate your help with this issue/behavior:
>
> ISSUE: I noticed that the last few messages on the Queue are not being issued 
> to onDelivery(Event) callback by the Reactor
> - Then, I went ahead and enabled proton Frame tracing (PN_TRACE_FRM=1) and 
> discovered that the Transfer frames corresponding to those messages were not 
> even delivered to Client. Then, I looked at our Service Proton Frames and can 
> clearly see that they are being delivered by the Service. And other AMQP 
> clients (for ex: .net client can see the Transfer frames)
> - Is this a known behavior?
> Does Reactor code path disable Nagle on underlying socket – could this be 
> related? or is there any other Configuration that we should be setting to see 
> all Transfer frames received on the Socket?
>
> Please advice.
>
> Thanks a lot in Advance!
> Sree
>
> Sent from Mail for Windows 10
>

I'm not aware of anyone else reporting anything like that. I don't see
anything in the code suggesting the reactor sets TCP_NODELAY trueon
the socket, but I wouldn't think that should matter here.

The frame trace logging is done after the bytes are given to the
Transport and are processed into frames, so a lack of logging could
suggest various things such as they didnt actually get there, they
werent processed, something went wrong before they did/were, something
went wrong decoding them, etc. Its hard to say much more without more
info.

Robbie

RE: Amqp-ConnProp: user-agent

[Garlapati Sreeram Kumar]

Can you please point me to those Symbols. I would love to not re-invent & reuse 
those …

Thx!
Sree

From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
Sent: Tuesday, April 5, 2016 10:14 AM
To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
Subject: Re: Amqp-ConnProp: user-agent

Many of the Qpid components advertise "product" and "version"
connection properties containing strings with the appropriate details.
Those [Symbol] keys were chosen because they happened to be names
specified in the older AMQP 0-x specs, and so matched what some of the
components were already using.

Robbie

On 5 April 2016 at 18:02, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
> Hello Folks!
>
> In our (Microsoft Azure EventHubs) java library, we are looking for a way to 
> identify which AmqpClient did the call originate from.
> We want to use this information to:
> 1) Identify client stack while troubleshooting Service issues - for ex: a bug 
> in implementation of AmqpProtocol stack
> 2) collect telemetry on how many different clients are talking to our service 
> (which will open-up data insights in future, for ex: investing our efforts on 
> the right client echo system etc.,)
>
> To achieve this - we are planning to introduce a Property (on AmqpConnection 
> -  [AMQP-CONNPROP]) to identify UserAgent.
> - We chose “Connection properties” – as this would be one-time per connection 
> and will not add extra overhead per message.
>
> I believe this would be a common requirement to all Amqp implementations. Are 
> you folks aware of any proposal to add a standard property to Amqp Protocol 
> Specification (or) is there already one that you folks use for this purpose – 
> in any of the Clients – which we can re-use and collectively propose to the 
> protocol spec.
>
> Thanks a lot for the Wonderful collaboration!
> Sree

Amqp-ConnProp: user-agent

[Garlapati Sreeram Kumar]

Hello Folks!

In our (Microsoft Azure EventHubs) java library, we are looking for a way to 
identify which AmqpClient did the call originate from. 
We want to use this information to:
1) Identify client stack while troubleshooting Service issues - for ex: a bug 
in implementation of AmqpProtocol stack
2) collect telemetry on how many different clients are talking to our service 
(which will open-up data insights in future, for ex: investing our efforts on 
the right client echo system etc.,)

To achieve this - we are planning to introduce a Property (on AmqpConnection -  
[AMQP-CONNPROP]) to identify UserAgent.
- We chose “Connection properties” – as this would be one-time per connection 
and will not add extra overhead per message.

I believe this would be a common requirement to all Amqp implementations. Are 
you folks aware of any proposal to add a standard property to Amqp Protocol 
Specification (or) is there already one that you folks use for this purpose – 
in any of the Clients – which we can re-use and collectively propose to the 
protocol spec.

Thanks a lot for the Wonderful collaboration!
Sree

Proton-j Reactor - Receiver

[Garlapati Sreeram Kumar]

Hello All!

I am using Proton-J reactor API (Version 0.12.0) for receiving AMQP Messages 
(from Microsoft Azure Event Hubs): 
https://github.com/Azure/azure-event-hubs/blob/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp/ReceiveLinkHandler.java#L124
 

Am using the onDelivery(Event) callback to receive messages. I really 
appreciate your help with this issue/behavior:

ISSUE: I noticed that the last few messages on the Queue are not being issued 
to onDelivery(Event) callback by the Reactor
- Then, I went ahead and enabled proton Frame tracing (PN_TRACE_FRM=1) and 
discovered that the Transfer frames corresponding to those messages were not 
even delivered to Client. Then, I looked at our Service Proton Frames and can 
clearly see that they are being delivered by the Service. And other AMQP 
clients (for ex: .net client can see the Transfer frames)
- Is this a known behavior? 
Does Reactor code path disable Nagle on underlying socket – could this be 
related? or is there any other Configuration that we should be setting to see 
all Transfer frames received on the Socket?

Please advice.

Thanks a lot in Advance!
Sree

Sent from Mail for Windows 10

RE: Proton-j: SendLink flow control

[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

Proton-j: SendLink flow control

[Garlapati Sreeram Kumar]

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

Proton-j: Receiver API Contracts

[Garlapati Sreeram Kumar]

Hello Folks,

Please help me understand few concepts on the usage of proton-j/reactor API:

While using the receiver – I am overriding BaseHandler.onDelivery 
event-callback to receive a batch of Messages. I am proactively flushing all 
available deliveries that comes as a batch – if available. Here’s pseudo-code 
of what I am doing – pls. correct if the intent is right. We are running into 
blocked Receiver when we are running 1 receiver per connection (using reactor 
framework) – does the below code ring any bells ?

while (delivery != null && delivery.isReadable() && 
!delivery.isPartial())
{
int size = delivery.pending();
byte[] buffer = new byte[size];
int read = receiveLink.recv(buffer, 0, buffer.length);

Message msg = Proton.message();
msg.decode(buffer, 0, read);

messages.add(msg);
deliveries.add(delivery);

if (!receiveLink.advance())
 {
break;
 }
 else
 {
delivery = receiveLink.current();
 }
}
application.onReceiveCallBack(messages);
for(Delivery unsettledDelivery: deliveries)
{
unsettledDelivery.settle();
}

- Qstn: on a Receiver, Under what circumstances will a delivery be not readable 
?   

Thanks a lot for the Collaboration effort!
Sree

proton-j reactor socket error recovery

[Garlapati Sreeram Kumar]

Hello All!

Question on reactor framework expected behavior:
- I am implementing an AmqpClient (for Azure EventHubs) and using 
reactor.connection(connxnHandler) to get a new out-bound connection and then 
creating sessions & Links (lets say a tree of 1 connxn – 1 session – 5 links). 
What happens on an event of socket errors? Is there a way to recover from the 
connection error and retain the same Connection-Session-Link hierarchy ? My 
question is more towards does Reactor provide any hooks to perform this Or do I 
need to maintain this mapping and recover from the situation. 

Thanks!
Sree

Best practices using proton-j Reactor

[Garlapati Sreeram Kumar]

Hello Folks!

Couple of Questions on Proton-j Reactor usage-pattern:

1. In the current version of proton-j: 1 Reactor instance is tied to 1 
connection – is there any way to associate 1 Reactor per Link.
Or in other words, If there are multiple links attached to one Connection, 
which is handled by one Reactor instance - What is the recommendation to use 
reactor in such a way that One link will not impact others – the unhandled 
exceptions and the time it takes to process.
Here’s the Problem: When one of the links perform I/O upon any event dispatched 
(ex: onDelivery) by the Reactor pump – all other links are starving for 
messages as that I/O is blocking the thread in which reactor.run() – which 
absolutely makes sense from Reactor pump (the reactor.run()) perspective. 

2. What is the Best way to gracefully Stop the Reactor.
In our Tests – where we  are Starting a Reactor per testclass and calling 
reactor.free as part of class cleanup – throws exception: 
reactor:org.apache.qpid.proton.engine.HandlerException: 
java.nio.channels.ClosedSelectorException
Do we need to handle this by try-catch’ing the reactor.run() block ?

Thanks a lot for such a Wonderful Collaboration!
Sree

proton 0.12 target release date

[Garlapati Sreeram Kumar]

Hello Folks!

Is there any target (or a ball-park of) release date for Proton-j 0.12 – when 
it shows up in the Maven repo @ 
https://search.maven.org/#search%7Cga%7C1%7Cproton-j

Thanks a lot for all the Help!
Sree

Re: Include PROTON-1096 in the release Proton-0.12

[Garlapati Sreeram Kumar]

Sounds very good.

Thanks a lot Robbie.!






Sree





From: Robbie Gemmell
Sent: ‎Wednesday‎, ‎January‎ ‎20‎, ‎2016 ‎11‎:‎48‎ ‎AM
To: proton@qpid.apache.org





Fear not Sreeram, the change will be included in 0.12.

The 0.12 alpha was cut from master mainly to serve as a heads up the
release process is going to get under way, and help tease out any
obvious issues before a 0.12.x branch is created to progress the
release via a beta and any subsequent fixups before RCs that can be
voted on. The branch hasnt been created yet, that will occur along
with the beta (originally due today, since postponed a little until
perhaps Monday).

Robbie

On 20 January 2016 at 19:36, Sreeram Kumar Garlapati
 wrote:
> Hello Folks,
>
> Need help getting a feature into proton-0.12 release train – the feature 
> request JIRA : PROTON-1096 
> (corresponding to the GitHub pull request: 
> https://github.com/apache/qpid-proton/pull/53).
>
> My bad. I pushed this change just before the fork of 0.12-alpha and created 
> this feature request against the release 0.12. I downloaded 0.12-alpha 
> (tar.gz) and built it and found that this pull-request missed Alpha. Can 
> someone please help how to get on to 0.12…
>
> PS: We (Windows Azure EventHubs team) are very close to releasing a 
> JavaClient for EventHubs based on 0.12 and badly need this feature for 
> enabling a very crucial scenario. Appreciate your help.
>
> Thanks!
> Sree
>