[
https://issues.apache.org/jira/browse/HADOOP-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13671692#comment-13671692
]
Daryn Sharp commented on HADOOP-9612:
-------------------------------------
Actually, it would also be great to actually propagate the interrupt. It's
very annoying right now that the client cannot be interrupted. For example, if
you run a FsShell command while the NN is down, you can pound on control-c but
the client ignores the exception and keeps retrying the connect.
> HADOOP client IPC layer should differentiate between interrupted threads and
> interrupts occurring during operations
> -------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-9612
> URL: https://issues.apache.org/jira/browse/HADOOP-9612
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 2.0.5-beta
> Environment: Ubuntu / x86_64
> Reporter: Gopal V
> Assignee: Gopal V
> Priority: Trivial
> Attachments: hdfs-interruptus.tgz
>
>
> Hadoop IPC throws misleading wrapped exceptions when operations are performed
> on threads which have already been interrupted.
> When a thread is already interrupted, the client IPC throws the following
> exception
> {code}
> Exception in thread "main" java.io.IOException:
> ...
> at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:761)
> at org.apache.hadoop.ipc.Client.call(Client.java:1270)
> at org.apache.hadoop.ipc.Client.call(Client.java:1218)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202)
> at $Proxy9.getBlockLocations(Unknown Source)
> {code}
> This is completely indistinguishable between a real interruption happening to
> the thread during the client call and very misleading.
> Before client calls, it would be prudent to check for the
> currentThread().isInterrupted() flag and throw a different exception to
> indicate the thread was already interrupted before the operation.
> The distinction between these two is a difference in exception messaging &
> backtrace, not the eventual exception thrown as such.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
