CASSANDRA-21212 Deleted Retired Command Stores#4668
CASSANDRA-21212 Deleted Retired Command Stores#4668alanwang67 wants to merge 9 commits intoapache:trunkfrom
Conversation
| { | ||
| try | ||
| { | ||
| if (epoch >= waitingForEpoch && AccordService.instance().topology().active().get(waitingForEpoch).retired().containsAll(waitingForRange)) |
There was a problem hiding this comment.
I would make waitingForRange non-final, and subtract from it the ranges we witness that supersede the epoch we're waiting on, so we don't need to continually consult global state
There was a problem hiding this comment.
Think I originally decided to go this way because there is a potential race condition between us calculating the exact ranges that need to be retired and the registering of the listener. But now that I think about it there is still a race condition in the way it's currently being done, except that if another range is retired afterwards then it is fine since we consult the global state.
Not sure if this is the canonical way to do things with listener timing, but just added an additional update to get any changes to the ranges that were retired that were done in between us calculating it and the registering of the listener.
| waitForEpochAndRangeRetirement wait = new waitForEpochAndRangeRetirement(condition, regainingEpochRange.epoch(), regainingEpochRange.range()); | ||
| AccordService.instance().topology().addListener(wait); | ||
| condition.awaitThrowUncheckedOnInterrupt(); | ||
| AccordService.instance().topology().removeListener(wait); |
There was a problem hiding this comment.
this should happen in a finally block
There was a problem hiding this comment.
Do you mean just the removeListener? Since if we put the whole code block in a finally then we don't wait for the ranges to be retired prior to TCM committing the start move.
2 participants
Adds a test for apache/cassandra-accord#269.