[
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)
