[
https://issues.apache.org/jira/browse/HTTPCORE-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McLellan updated HTTPCORE-367:
-----------------------------------
Description:
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:
<blockquote>
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();
}
}
</blockquote>
Has been replaced with:
<blockquote>
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;
}
}
}
</blockquote>
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.
was:
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:
{code}
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();
}
}
{code}
Has been replaced with:
{code}
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;
}
}
}
{code}
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.
> 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
>
> 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:
> <blockquote>
> 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();
> }
> }
> </blockquote>
> Has been replaced with:
> <blockquote>
> 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;
> }
> }
> }
> </blockquote>
> 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]
