Sigma-Ma commented on code in PR #8566:
URL: https://github.com/apache/hbase/pull/8566#discussion_r3990512176
##########
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java:
##########
@@ -1257,18 +1263,155 @@ private void parallelSeek(final List<? extends
KeyValueScanner> scanners, final
latch.countDown();
}
}
+ InterruptedIOException interruptedException = null;
+ while(true) {
+ try {
+ latch.await();
+ break;
+ } catch (InterruptedException ie) {
+ interruptedException = (InterruptedIOException) new
InterruptedIOException().initCause(ie);
+ }
+ }
+ if (interruptedException != null) {
Review Comment:
Thanks for opening HBASE-30375. I agree this deserves a separate discussion
covering both seek paths.
I haven't traced all the interrupt sources yet. RpcExecutor.stop() does
interrupt RPC handlers, but I'd check the timeout and region-close paths
separately before assuming they behave the same way.
My initial preference would be to keep waiting for running handlers as the
baseline, then consider cancellation to reduce the wait. Even with
cancel(true), we'd still need to know that a handler has actually stopped using
its scanner before allowing cleanup. A cancelled Future alone doesn't guarantee
that.
I'd be cautious about adding a timeout without also defining who owns and
closes the scanners afterwards. Otherwise, we could end up with the same
close-while-seeking race once the timeout expires.
One detail to account for is cancellation before a handler starts: its
process() finally block won't run, so the latch needs to be accounted for
exactly once elsewhere. Tasks removed during executor shutdown need similar
consideration. Tests for these cases, and for a running seek that doesn't
respond promptly to interruption, would help us compare the options.
I think HBASE-30375 is a good place to work through this and get input from
others who know these paths better.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
