hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McLellan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-367) DefaultNHttpClientConnection enters infinite loop when consuming chunked response
Date Fri, 13 Dec 2013 18:01:11 GMT

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

Paul McLellan commented on HTTPCORE-367:
----------------------------------------

Hi Oleg,

thanks for the quick response. I'll test against the latest snapshot and let you know how
things look.

Just realised there was one detail I forgot to mention: this problem relates to an SSL connection.
As you mentioned, the ChunkDecoder was repeatedly trying to read from the underlying channel.
However, the SSLIOSession had no data available for consumption because its 'isAppInputReady()'
method was not being invoked between read attempts. In the old version of the code this would
happen at the AbstractIODispatch level once the thread had returned from calling DefaultNHttpClientConnection.consumeInput.
I think this is what causes the dispatcher to become stuck indefinitely. 

Sorry, not sure if that's a great explanation of what was going on. Does it make sense?

Thanks,
Paul

> DefaultNHttpClientConnection enters infinite loop when consuming chunked response
> ---------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-367
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-367
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.3
>         Environment: Java 1.7.0_40
>            Reporter: Paul McLellan
>             Fix For: 4.3.1
>
>
> We recently upgraded from 4.3-beta2 to 4.3 and noticed that our client was not fully
consuming large (~64K) responses from the server. A little digging led us to the 'consumeInput(NHttpClientEventHandler)'
method of DefaultNHttpClientConnection. Within this method, the following logic from 4.3-beta2:
> if (this.contentDecoder != null && (this.session.getEventMask() & SelectionKey.OP_READ)
> 0) {
>     handler.inputReady(this, this.contentDecoder);
>     if (this.contentDecoder.isCompleted()) {
>         // Response entity received
>         // Ready to receive a new response
>         resetInput();
>     }
> }
> Has been replaced with:
> if (this.contentDecoder != null) {
>     // Loop until there is interest in input,
>     // decoder is not done and there is buffered session data
>     while ((this.session.getEventMask() & SelectionKey.OP_READ) > 0) {
>         handler.inputReady(this, this.contentDecoder);
>         if (this.contentDecoder.isCompleted()) {
>             // Response entity received
>             // Ready to receive a new response
>             resetInput();
>             break;
>         }
>         if (!this.inbuf.hasData()) {
>             break;
>         }
>     }
> }
> This is causing the dispatcher thread to become stuck in an infinite loop when it reaches
the end of the first chunk because the input buffer contains a single character ('\r') that
is never consumed by the ChunkDecoder. Prior to the upgrade this method would exit and the
dispatcher thread would be able to read the next chunk from the inbound channel.
> Can you help with this issue please? Any assistance/guidance would be greatly appreciated.
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message