cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9329) Make CAS retry logic configurable
Date Fri, 08 May 2015 13:14:00 GMT

    [ 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)

Mime
View raw message