[
https://issues.apache.org/jira/browse/HADOOP-8350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267670#comment-13267670
]
Todd Lipcon commented on HADOOP-8350:
-------------------------------------
Attached patch does the following:
- introduces a new SocketInputWrapper class. In the case that the socket has a
channel, this wraps the existing NIO-based SocketInputStream implementation.
Otherwise, it just wraps the InputStream provided by Java's
Socket.getInputStream. This wrapper also contains a call to set the timeout,
which either propagates the timeout to the NIO implementation's
SocketIOWithTimeout, or propagates to Socket.setTimeout(), as appropriate.
- sets SocketInputStream back to being package-private, now that its
functionality is exposed by SocketInputWrapper. It used to be this way, and
it's always been annotated LimitedPrivate, so this isn't incompatible.
- Fixed TestSocketIOWithTimeout to use MultithreadedTestUtil.TestContext. It
previously assumed that "fail()" in an inferior thread would cause the test
case to fail, which is not the case. Also amended this test to test the
setTimeout() call.
There's one small cross-project change to HDFS's RemoteBlockReader2 here to use
the new API. I ran a few HDFS client test cases manually to make sure I didn't
break anything there.
> Improve NetUtils.getInputStream to return a stream which has a tunable timeout
> ------------------------------------------------------------------------------
>
> Key: HADOOP-8350
> URL: https://issues.apache.org/jira/browse/HADOOP-8350
> Project: Hadoop Common
> Issue Type: Improvement
> Components: util
> Affects Versions: 1.0.0, 2.0.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Attachments: hadoop-8350.txt
>
>
> Currently, NetUtils.getInputStream will set the timeout on the new stream
> based on the socket's configured timeout at the time of construction. After
> that, the timeout cannot be changed. This causes a problem for cases like
> HDFS-3357. One approach used in some places in the code is to construct new
> streams when the timeout has to be changed, but this can cause bugs given
> that the streams are often wrapped by BufferedInputStreams.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
