[jira] [Commented] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239886#comment-15239886
 ] 

ASF GitHub Bot commented on PROTON-1171:


Github user SreeramGarlapati commented on the pull request:

https://github.com/apache/qpid-proton/pull/73#issuecomment-209605630
  
This is huge. Thanks @gemmellr !
We validated this in our stress run - you are correct - with my fix - we 
were still hitting another issue - which I was still looking at. After I packed 
proton with your commit - we are completely unblocked from receive stuck issue.

Looking forward for 0.12.2.


> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton 0.12.2 release

[Robbie Gemmell]

Hi Frank,

That isn't one I can be much help with, being proton-c and Messenger,
neither of which I'm much use with. If someone looks at it in time,
great, but it seems more likely it won't squeeze into 0.12.2 at this
point. I was really just calling for any previously-committed bug
fixes folks wanted to have considered ahead of 0.13.0 (due later in
the month).

As an aside, it might be useful (but also might not..) if you put up
protocol trace logs of a run showing the issue you are seeing
(environment variable PN_TRACE_FRM=1 for proton-c, I think).

Robbie

On 13 April 2016 at 17:02, Frank Quinn  wrote:
> Hi Robbie,
>
> Would appreciate if someone could take a look at this one:
> https://issues.apache.org/jira/browse/PROTON-1169
>
> Cheers,
> Frank
>
> On Wed, Apr 13, 2016 at 3:11 PM, Robbie Gemmell 
> wrote:
>
>> Hi folks,
>>
>> I'd like to do a 0.12.2 release to incorporate a proton-j fix for
>> https://issues.apache.org/jira/browse/PROTON-1171. If all goes well
>> with feedback on that change I would propose to spin a release
>> candidate in the next day or so.
>>
>> If you have any targetted bug fixes you would like to include ahead of
>> the imminent 0.13.0 release cycle, now would be the time to think
>> about it.
>>
>> Robbie
>>

Re: Dropping proton-dump; Moving to newer minimum CMake version

[Chuck Rolke]

A multi-frame issues showed up at 
https://issues.apache.org/jira/browse/DISPATCH-263 and I think proton-dump was 
useful in figuring it out. 

Wireshark marked dozens of frames with decode errors. proton-dump[1] came to 
the rescue was able to grind through the packets without complaining. Problem 
analysis could immediately move beyond figuring out what's wrong with the data 
stream because it was fine.

I don't need to add proton-dump back into the source tree but I have it built 
and ready for the occasional need.

-Chuck

[1] proton-dump was opening the dump files in text mode and causing a confusing 
truncation error. If you plan to use proton-dump you should apply this:

diff --git a/proton-c/src/proton-dump.c b/proton-c/src/proton-dump.c
index 1ce577d..f0718ac 100644
--- a/proton-c/src/proton-dump.c
+++ b/proton-c/src/proton-dump.c
@@ -39,7 +39,7 @@ void fatal_error(const char *msg, const char *arg, int err)

 int dump(const char *file)
 {
-  FILE *in = fopen(file, "r");
+  FILE *in = fopen(file, "rb");
   if (!in) fatal_error("proton-dump: dump: opening %s", file, errno);

   pn_buffer_t *buf = pn_buffer(1024);

- Original Message -
> From: "Andrew Stitcher" 
> To: proton@qpid.apache.org, "Qpid Developers" 
> Sent: Friday, February 19, 2016 10:04:40 AM
> Subject: Re: Dropping proton-dump; Moving to newer minimum CMake version
> 
> Well I left it 3 days, heard no objections so I will remove proton-dump
> and up the minimum version of cmake to 2.8.7.
> 
> Andrew
> 
> 

Re: Proton 0.12.2 release

[Frank Quinn]

Hi Robbie,

Would appreciate if someone could take a look at this one:
https://issues.apache.org/jira/browse/PROTON-1169

Cheers,
Frank

On Wed, Apr 13, 2016 at 3:11 PM, Robbie Gemmell 
wrote:

> Hi folks,
>
> I'd like to do a 0.12.2 release to incorporate a proton-j fix for
> https://issues.apache.org/jira/browse/PROTON-1171. If all goes well
> with feedback on that change I would propose to spin a release
> candidate in the next day or so.
>
> If you have any targetted bug fixes you would like to include ahead of
> the imminent 0.13.0 release cycle, now would be the time to think
> about it.
>
> Robbie
>

Proton 0.12.2 release

[Robbie Gemmell]

Hi folks,

I'd like to do a 0.12.2 release to incorporate a proton-j fix for
https://issues.apache.org/jira/browse/PROTON-1171. If all goes well
with feedback on that change I would propose to spin a release
candidate in the next day or so.

If you have any targetted bug fixes you would like to include ahead of
the imminent 0.13.0 release cycle, now would be the time to think
about it.

Robbie

[jira] [Commented] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239286#comment-15239286
 ] 

ASF GitHub Bot commented on PROTON-1171:


Github user gemmellr commented on the pull request:

https://github.com/apache/qpid-proton/pull/73#issuecomment-209455781
  
I have made a change that should resolve this. Its a little different than 
your proposal to both resolve an issue with it (unlikely but possible infinite 
loop), and also change some other existing behaviours I found while digging 
into it. If you could give it a try with your bits and report back that would 
be great.


> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] qpid-proton pull request: PROTON-1171: SimpleSSLTransportWrapper d...

[gemmellr]

Github user gemmellr commented on the pull request:

https://github.com/apache/qpid-proton/pull/73#issuecomment-209455781
  
I have made a change that should resolve this. Its a little different than 
your proposal to both resolve an issue with it (unlikely but possible infinite 
loop), and also change some other existing behaviours I found while digging 
into it. If you could give it a try with your bits and report back that would 
be great.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239273#comment-15239273
 ] 

ASF GitHub Bot commented on PROTON-1171:


Github user asfgit closed the pull request at:

https://github.com/apache/qpid-proton/pull/73


> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] qpid-proton pull request: PROTON-1171: SimpleSSLTransportWrapper d...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-proton/pull/73


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239272#comment-15239272
 ] 

ASF subversion and git services commented on PROTON-1171:
-

Commit 3ea4287d483f3ce275be75bf50ac1728527d697a in qpid-proton's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3ea4287 ]

PROTON-1171: update transport ssl wrapper to ensure attempt to pass all decoded 
bytes to the underlying input or throw, and avoid processing the underlying 
layer when no bytes have been passed on

This closes #73


> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1171:
---
Fix Version/s: 0.12.2

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1171:
---
Affects Version/s: 0.12.1

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reassigned PROTON-1171:
--

Assignee: Robbie Gemmell

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0, 0.12.1
> Environment: Any
>Reporter: Sreeram Garlapati
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.13.0, 0.12.2
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1171) [proton-j] transport SSL wrapper does not flush all decoded bytes to the underlying input

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1171:
---
Summary: [proton-j] transport SSL wrapper does not flush all decoded bytes 
to the underlying input  (was: proton-j: SimpleSSLTransportWrapper doesn't 
flush all bytes from the Decode buffer to the next transport buffer 
(_underlyingInput))

> [proton-j] transport SSL wrapper does not flush all decoded bytes to the 
> underlying input
> -
>
> Key: PROTON-1171
> URL: https://issues.apache.org/jira/browse/PROTON-1171
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
> Environment: Any
>Reporter: Sreeram Garlapati
>Priority: Critical
> Fix For: 0.13.0
>
>
> Actual Issue/scenario hit by Microsoft Azure EventHubs:
>  We have a pattern where customers sends messages in a burst to our Queue and 
> stop sending and then wait for all of them to be received.
> Because of this issue in Proton-j Amqp implementation - we can see many bytes 
> were stuck in the SSL Decode Buffer and were only picked up when new 
> transport frames arrive.
> Given that this is a 1 line fix - it would be great if you folks can publish 
> an incremental minor update to 0.12.X.
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)