[ https://issues.apache.org/jira/browse/HBASE-10516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903302#comment-13903302 ]
Nicolas Liochon commented on HBASE-10516: ----------------------------------------- sleepBeforeRetry => sure createDir => why not thowing an InterrupedIOException? rename => same deleteDir => same HRegionServer#waitOnAllRegionsToClose => I suppose it's the best option For InterrupedIOException, my *feeling* is that we can already receive these exceptions today (as we're going network & disk operations, they are likely to check the interrupt status already, or may do it in the future). > 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 > > > 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)