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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org

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

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

Commit 91aff1316bbbc7941a6f5fe8d3e0366744896186 in qpid-proton's branch refs/heads/0.12.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=91aff13 ]

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

(cherry picked from commit 3ea4287d483f3ce275be75bf50ac1728527d697a)


> [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)