[ 
https://issues.apache.org/jira/browse/HADOOP-17779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372796#comment-17372796
 ] 

David Mollitor commented on HADOOP-17779:
-----------------------------------------

[[email protected]] Thanks for the feedback.

I ran into this issue, as reported, here:

https://issues.apache.org/jira/browse/HIVE-24484?focusedCommentId=17371600&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17371600

So ya, we had to put in some hackiness to workaround this change as previously 
relying on the standard {{InterruptedException}} was enough, now there needs to 
handle {{InterruptedIOException}} as well, which I would argue is a breaking 
change.

Anything related to networking, etc, should have a timeout to kill the 
connection, not to mention, the scenario you described is currently the case 
now.  If a thread has the semaphore and is stuck on a Socket connection, 
interrupting that thread does not kill the connection.  The thread will only 
unblock from the socket operation if the socket is closed, the socket is not 
connected, or the socket input has been shutdown using {{shutdownInput()}}.

> Lock File System Creator Semaphore Uninterruptibly
> --------------------------------------------------
>
>                 Key: HADOOP-17779
>                 URL: https://issues.apache.org/jira/browse/HADOOP-17779
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: fs
>    Affects Versions: 3.3.1
>            Reporter: David Mollitor
>            Assignee: David Mollitor
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{FileSystem}} "creator permits" are acquired in an interruptable way.  This 
> changed the behavior of the call because previous callers were handling the 
> IOException as a critical error.  An interrupt was handled in the typical 
> {{InterruptedException}} way.  Lastly, there was no documentation of this new 
> event so again, callers are not prepared.
> Restore the previous behavior and lock the semaphore Uninterruptibly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to