You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Jan Hallonsten (JIRA)" <ji...@apache.org> on 2018/09/03 10:27:00 UTC
[jira] [Updated] (CXF-7831) SocketTimeoutException when previous
response was exactly chunk length bytes
[ 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)