dcapwell commented on code in PR #3656:
URL: https://github.com/apache/cassandra/pull/3656#discussion_r1830251288
##########
test/distributed/org/apache/cassandra/distributed/impl/Instance.java:
##########
@@ -651,7 +666,28 @@ public void startup(ICluster cluster)
throw (RuntimeException) t;
throw new RuntimeException(t);
}
- }).run();
+ }).call();
+ DurationSpec timeout = startupTimeout();
+ if (timeout == null)
+ {
+ waitOn(result);
+ }
+ else
+ {
+ try
+ {
+ result.get(timeout.quantity(), timeout.unit());
+ }
+ catch (InterruptedException e)
+ {
+ Thread.currentThread().interrupt();
Review Comment:
there are 2 methods on `Thread` and it depends on what gets called
`interrupted()` this clears the result as you are expected to handle
`isInterrupted()` this does not clear
You as the catcher have no clue what was called! In Effective Java the
recommended pattern is to re-interrupt the thread (it's just a flag) to make
sure that the caller that catches your throwable can still see the interrupt.
If you do not re-interrupt the thread then its possible that this gets
ignored and we swallow the interrupt; which is why effective java tells you to
do this.
There are cases where clearing it makes sense, such as being interrupted to
*release resources*, but since our code base doesn't do that, it only means
"shutdown" for us, so making sure we don't loose the interrupt is best as
general statement
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
