[
https://issues.apache.org/jira/browse/CASSANDRA-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534465#comment-14534465
]
Sylvain Lebresne commented on CASSANDRA-9329:
---------------------------------------------
bq. the internal CAS retry loop (when the condition is not met)
The internal CAS retry loop is *not* taken when the condition is met, it's
taken on internal contention of the Paxos algorithm. The sleep exists so that
the algorithm has a better chance to actually do progress as replaying
aggressively will almost surely incur more contention. Disabling the retry loop
would also mean throwing an exception since we can't answer either positively
or negatively which would be really messy, and is leaking way too much
implementation details.
The {{100ms}} hardcoded value is however arguably a bit random and exposing it
so people can experiment with the value could make sense. I however doubt there
is much to win by changing the "algorithm" uses so I don't think it's worth the
complexity of exposing it (unless you can demonstrate that different choice
make measurable differences in different cases).
> Make CAS retry logic configurable
> ---------------------------------
>
> Key: CASSANDRA-9329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9329
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Aaron Whiteside
> Fix For: 3.x
>
>
> Make CAS retry logic configurable:
> One should be able to disable the internal CAS retry loop (when the condition
> is not met) and let the client choose how to do retries (so the client does
> not have to incur the server side random sleep of up to 100ms). Basically let
> the client handle all CAS retries in a manor it sees fit.
> Secondly the hardcoded sleep up to 100ms that happens when cassandra fails to
> meet the CAS condition should be configurable.
> - The max duration should be configurable
> - The algorithm used to choose the duration should be configurable (Random,
> Exponential, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
