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

Reply via email to