[
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: [email protected]
For additional commands, e-mail: [email protected]
