[
https://issues.apache.org/jira/browse/HBASE-10516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903994#comment-13903994
]
Nicolas Liochon commented on HBASE-10516:
-----------------------------------------
bq. Should we treat it case-by-case, or per-class, or uniformly for all
occurrences?
There is a general strategy, then the exceptions :-).
I think we agree on the general strategy, let me formulate it to confirm:
- never never never shallow IE
- if possible, stop the current task, if not possible, continue, and manage
the interruption when the non interruptible task has been done
- try to throw a clear exception (IE or IOE), if not restore the status
"catch and rethrow a RuntimeException instead" is generally bad. It means that
you do not accept to be interrupted. So we should not add such kind of code.
But in such a code
void f(){
partOne(); //shallows exception
partTwo(); // throw Runtime on Exception
}
It's acceptable, imho, to change the part one to make it throws the same
runtime as the part 2.
> Refactor code where Threads.sleep is called within a while/for loop
> -------------------------------------------------------------------
>
> Key: HBASE-10516
> URL: https://issues.apache.org/jira/browse/HBASE-10516
> Project: HBase
> Issue Type: Bug
> Components: Client, master, regionserver
> Reporter: Feng Honghua
> Assignee: Feng Honghua
> Attachments: HBASE-10516-trunk_v1.patch, HBASE-10516-trunk_v2.patch
>
>
> Threads.sleep implementation:
> {code}
> public static void sleep(long millis) {
> try {
> Thread.sleep(millis);
> } catch (InterruptedException e) {
> e.printStackTrace();
> Thread.currentThread().interrupt();
> }
> }
> {code}
> From above implementation, the current thread's interrupt status is
> restored/reset when InterruptedException is caught and handled. If this
> method is called within a while/for loop, if a first InterruptedException is
> thrown during sleep, it will make the Threads.sleep in next loop immediately
> throw InterruptedException without expected sleep. This behavior breaks the
> intention for independent sleep in each loop
> I mentioned above in HBASE-10497 and this jira is created to handle it
> separately per [~nkeywal]'s suggestion
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
