Ichsan Said created HBASE-30375:
-----------------------------------
Summary: Restore interrupt status before throwing in parallelSeek
Key: HBASE-30375
URL: https://issues.apache.org/jira/browse/HBASE-30375
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: Ichsan Said
CountDownLatch.await() clears the interrupt flag when it throws
InterruptedException. Currently parallelSeek does not restore the interrupt
status before throwing InterruptedIOException, so callers checking
Thread.currentThread().isInterrupted() after catching the exception will
see a cleared flag.
adaptiveParallelSeek (introduced in HBASE-30327) already handles this
correctly, it waits for all submitted handlers to finish before throwing,
then restores the interrupt status. parallelSeek should be updated
consistently.
However, this raises a broader concern: when the caller thread is interrupted,
what is the right behavior for already-submitted handlers?
Option 1: Wait for all submitted handlers to finish (current
adaptiveParallelSeek
behavior). Safe from a resource perspective, no scanner is closed while a
worker still holds a reference. But if the interrupt is a stop signal (e.g.
RPC timeout, region close), waiting for handlers doing slow disk/HDFS I/O
could delay the response noticeably.
Option 2: Cancel submitted handlers before waiting on the latch, so workers
can bail out quickly. Requires submitting via Future to call cancel(true),
which is a non-trivial refactor from the current executor.submit(handler)
pattern.
Option 3: Add a bounded timeout to latch.await(), so we do not wait
indefinitely but still give handlers a chance to finish cleanly.
Any fix should cover both parallelSeek and adaptiveParallelSeek (HBASE-30327)
consistently. Input on the preferred approach is welcome.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
