dcapwell commented on code in PR #57:
URL: https://github.com/apache/cassandra-accord/pull/57#discussion_r1303381499
##########
accord-core/src/test/java/accord/burn/BurnTest.java:
##########
@@ -230,37 +237,50 @@ static void burn(RandomSource random, TopologyFactory
topologyFactory, List<Id>
// not used for atomicity, just for encapsulation
AtomicReference<Runnable> onSubmitted = new AtomicReference<>();
- Consumer<Packet> responseSink = packet -> {
- ListResult reply = (ListResult) packet.message;
- if (replies[(int)packet.replyId] != null)
- return;
-
+ Runnable maybeTriggerNextRequest = () -> {
Review Comment:
> as we will enqueue for both the heartbeat and any future response.
"should" there be any "future responses"? We send the heart beat IFF the
client saw a failure (other than Invalidated) and enqueue trying to figure out
the state in `onDone`. `onDone` is only triggered once we finished processing
all the inflight work, which implies the response sink stopped enqueueing work.
So the "future responses" should only be after we have finished enqueueing all
work
The issue I saw was that we stopped enqueuing work, so we fail with `throw
new AssertionError("Incomplete set of responses; clock=" + clock.get() + ",
expected operations=" + (operations * 2));`. The root cause I found was that
if we don't enqueue on the heart beat there are conditions where we stop
progressing the backlog and complete early and fail as the expected amount of
operations didn't happen.
--
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]
