[ https://issues.apache.org/jira/browse/HBASE-10516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Feng Honghua updated HBASE-10516: --------------------------------- Attachment: HBASE-10516-trunk_v1.patch Two notes: # The fix of Threads.sleep in JVMClusterUtil.java has been included in HBASE-10523, so no fix here # Though Threads.sleep is not within a loop its immediate containing method in HRegionFileSystem.java, that method does be called within do-while loops in many other methods, so also need to be fixed and the fix is not straightforward > 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, and even worse can incur > infinite loop for while(true)-like loop where the exit condition check occurs > after sleep statement within the while 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)