[
https://issues.apache.org/jira/browse/HBASE-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916909#action_12916909
]
stack commented on HBASE-3064:
------------------------------
Over in the new master, we let out all InterruptedExceptions now. As you
suggest, we should do same in client. The change will be disruptive though in
that it'll change APIs since we'll have to add IE as thrown to all methods.
So, I think we should apply this patch for 0.90 and then make a new issue to
add IE to client APIs for 0.92? Hows that sound? If agreeable I'll apply this
patch (it looks good).
> Long sleeping in HConnectionManager after thread is interrupted
> ---------------------------------------------------------------
>
> Key: HBASE-3064
> URL: https://issues.apache.org/jira/browse/HBASE-3064
> Project: HBase
> Issue Type: Bug
> Components: client, ipc
> Reporter: Bruno Dumon
> Attachments: connectionmgr-interruptedexc-patch.txt
>
>
> We run sometimes into the problem that when a thread running HBase client
> code is interrupted, it hangs. The problem is it is sleeping in
> HConnectionManager, in the methods locateRegionInMeta and
> getRegionServerWithRetries, where there is code like this:
> {code}
> try{
> Thread.sleep(getPauseTime(tries));
> } catch (InterruptedException e) {
> // continue
> }
> {code}
> which is located in a for-loop, so it will keep retrying even when someone
> requested the thread to stop its work.
> The attached patch proposes as fix to re-assert the interrupted status of the
> thread and to throw an IOException. Some other cases of
> InterruptedException-handling in the same class do a similar thing, though
> sometimes returning null or breaking. I found returning null causes NPE's in
> other locations so I think it is better to throw an informative exception.
> Side thought: I would not be against propagating the InterruptedException all
> the way up to the client APIs (HTable/HBaseAdmin), so that users who want to
> support interruptable threads do not have to check the interrupted flag. I'd
> need to check some more but I have the impression that now sometimes methods
> like HTable.get() simply return null when a thread is interrupted.
> Some background on good ways of handling InterruptedExceptions can be found
> here:
> http://www.ibm.com/developerworks/java/library/j-jtp05236.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
