ExecuteSyncPoint and Fetch now throw Timeout if all sub-errors are Ti…#3379
ExecuteSyncPoint and Fetch now throw Timeout if all sub-errors are Ti…#3379dcapwell merged 1 commit intoapache:cep-15-accordfrom
Conversation
There was a problem hiding this comment.
spoke with @bdeggleston about this in slack, this timeout is too large and using an unrelated config (bootstrap and repair are not the same thing). This isn't 100% related to this patch as its from my topology fix patch, but trying to pull out bug fixes to make reviews easier
There was a problem hiding this comment.
Mostly refactored to make the tests easier (as they count calls to sleep) and make it clear when we backoff; which is only when the type of error is expected.
There was a problem hiding this comment.
this is possible on the JVM, but super tacky to hit this case... you either do this outside of javac or trick javac... In the common case (most likely 100%) we will return from the previous line
There was a problem hiding this comment.
I punted on trying to fix the test... we actually don't stream anything....
There was a problem hiding this comment.
I punted on trying to fix the test... we actually don't stream anything....
There was a problem hiding this comment.
I literally just encountered the Preempted == timeout issue in my testing today.
There was a problem hiding this comment.
if its jvm-dtest there is a function to retry read/writes (assuming they are idempotent, else we fail)... both are timeouts from a users point of view...
There was a problem hiding this comment.
We can only hit exhausted for reads and specifically barriers?
There was a problem hiding this comment.
I saw other code paths that use it as well, but they are not user facing; CoordinateGloballyDurable (background task), and FetchCoordinator (bootstrap / streaming of ranges)
There was a problem hiding this comment.
I didn't want to touch those as the coverage is mostly via BurnTest so subtle changes can take a long time to detect issues.
…Timeout and doesn’t get retried patch by David Capwell; reviewed by Ariel Weisberg for CASSANDRA-19718
dcapwell
force-pushed
the
CASSANDRA-19718
branch
from
74181de to
fbd9e28
Compare
2 participants
No description provided.