[
https://issues.apache.org/jira/browse/CXF-7831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hallonsten updated CXF-7831:
--------------------------------
Description:
When using the Asynchronous Client HTTP Transport we get a SocketTimeout
exception when the previous response was exactly the same length as the chunk
length by default 16320 bytes.
After some investigation we have found that the problem is that when the http
connection is returned to PoolingNHttpClientConnectionManager the
SelectionKey's interestOps does not contain OP_READ. The input gets suspended
in SharedInputBuffer when the buffer is full (16320 bytes by default) if this
happens at the same time as the endOfStream is reached more input is never
requested. We have fixed it locally by adding an endOfStream check before
suspending input in SharedInputBuffer. This might not be the correct place to
fix it since you could argue that it should not be the responsibility of the
user of PoolingNHttpClientConnectionManager to return the http connection in
the correct state.
An example project to reproduce the problem is attached in asyncbugtest.zip and
a patch with our fix is in Check_endOfStream_before_suspending_input.patch
was:
When using the Asynchronous Client HTTP Transport we get a SocketTimeout
exception when the previous response was exactly the same length as the chunk
length by default 16320 bytes.
After some investigation we have found that the problem is that when the http
connection is returned to PoolingNHttpClientConnectionManager the
SelectionKey's interestOps does not contain OP_READ. The input gets suspended
in SharedInputBuffer when the buffer is full (16320 bytes by default) if this
happens at the same time as the endOfStream is reached more input is never
requested. We have fixed it locally by adding an endOfStream check before
supsending input in SharedInputBuffer. This might not be the correct place to
fix it since you could argue that it should not be the responsibility of the
user of PoolingNHttpClientConnectionManager to return the http connection in
the correct state.
An example project to reproduce the problem is attached in asyncbugtest.zip and
a patch with our fix is in Check_endOfStream_before_suspending_input.patch
> SocketTimeoutException when previous response was exactly chunk length bytes
> ----------------------------------------------------------------------------
>
> Key: CXF-7831
> URL: https://issues.apache.org/jira/browse/CXF-7831
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 3.2.6
> Reporter: Jan Hallonsten
> Priority: Major
> Attachments: Check_endOfStream_before_suspending_input.patch,
> asyncbugtest.zip
>
>
> When using the Asynchronous Client HTTP Transport we get a SocketTimeout
> exception when the previous response was exactly the same length as the chunk
> length by default 16320 bytes.
> After some investigation we have found that the problem is that when the http
> connection is returned to PoolingNHttpClientConnectionManager the
> SelectionKey's interestOps does not contain OP_READ. The input gets suspended
> in SharedInputBuffer when the buffer is full (16320 bytes by default) if this
> happens at the same time as the endOfStream is reached more input is never
> requested. We have fixed it locally by adding an endOfStream check before
> suspending input in SharedInputBuffer. This might not be the correct place to
> fix it since you could argue that it should not be the responsibility of the
> user of PoolingNHttpClientConnectionManager to return the http connection in
> the correct state.
>
> An example project to reproduce the problem is attached in asyncbugtest.zip
> and a patch with our fix is in Check_endOfStream_before_suspending_input.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
