Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Fri, 13 Dec 2013 09:16:10 +0000 (UTC)
From: "Oleg Kalnichevski (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12684362.1386886794851.31127.1386926170770@arcas>
In-Reply-To: <JIRA.12684362.1386886794851@arcas>
References: <JIRA.12684362.1386886794851@arcas>
Subject: [jira] [Comment Edited] (HTTPCORE-367) DefaultNHttpClientConnection
 enters infinite loop when consuming chunked response
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Oleg Kalnichevski edited comment on HTTPCORE-367 at 12/13/13 9:15 AM:
----------------------------------------------------------------------

Paul,
Some things do not seem to quite add up. Non-blocking content decoders including ChunkDecoder can read from the underlying channel whenever more data is needed to compete the decoding process. What can happen though that the #consumeInput method ends up in a tight loop if a chunk header happens to get split across multiple TCP frames while waiting for the next TCP frame to arrive. However, it should never get stuck in that loop indefinitely, unless I am still missing something important here.

In any case tight loop is a serious matter and I reverted the revision that had caused this regression.

Please re-test your application with the latest SVN snapshot and let me know if everything works as expected.

Oleg


was (Author: olegk):
Paul,
Some things do not seem to quite add up. Non-blocking content decoders including ChunkDecoder can read from the underlying channel whenever more data to compete the decoding process. What can happen though that the #consumeInput method ends up in a tight loop if a chunk header happens to get split across multiple TCP frames while waiting for the next TCP frame to arrive. However, it should never get stuck in that loop indefinitely, unless I am still missing something important here.

In any case tight loop is a serious matter and I reverted the revision that had caused this regression.

Please re-test your application with the latest SVN snapshot and let me know if everything works as expected.

Oleg

> 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