[
https://issues.apache.org/jira/browse/HDFS-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047404#comment-13047404
]
Kihwal Lee commented on HDFS-2054:
----------------------------------
@Todd: (b) may not work either. TransferTo() accesses fd directly and nothing
sets the class private variables for indicating the connection status in
objects that uses it (e.g. Socket). SocketChannel.write() will also cause EPIPE
and an ioe at this point. Only after close() method is explicitly called, the
private variables are set and subsequently the open/close check methods will
work as expected. Reading may work if the read buffer is not empty even after a
write got EPIPE. So testing the connection with read is not reliable either.
o.a.h.net.SocketOutputStream.write() used in other portions of sendChunks()
does catch IOException and close the stream. That's the source of the isOpen()
inconsistency I reported above.
The NIO could check for EPIPE and make an AsynchronousCloseException thrown in
FileChannel. Otherwise it is very hard to handle different types of exceptions
in different ways. For SocketChannel, most Java code assumes IOException means
connection closure. The same assumption cannot be made in FileChannel (e.g.
HDFS-1527).
Short of the support from NIO, (a) seems to be the only option. We could do
this in o.a.h.net.SocketOutputStream.transferToFully(), but the hadoop-common
class might be used by others and connection closure be handled by catching
IOException. So the safest thing we can do at this point is adding (a) to
BlockSender.
> BlockSender.sendChunk() prints ERROR for connection closures encountered
> during transferToFully()
> --------------------------------------------------------------------------------------------------
>
> Key: HDFS-2054
> URL: https://issues.apache.org/jira/browse/HDFS-2054
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: data-node
> Affects Versions: 0.22.0, 0.23.0
> Reporter: Kihwal Lee
> Assignee: Kihwal Lee
> Priority: Minor
> Attachments: HDFS-2054.patch
>
>
> The addition of ERROR was part of HDFS-1527. In environments where clients
> tear down FSInputStream/connection before reaching the end of stream, this
> error message often pops up. Since these are not really errors and especially
> not the fault of data node, the message should be toned down at least.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
