You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeremy Hanna (JIRA)" <ji...@apache.org> on 2018/05/11 12:56:01 UTC
[jira] [Updated] (CASSANDRA-8672) Ambiguous WriteTimeoutException
while completing pending CAS commits
[ https://issues.apache.org/jira/browse/CASSANDRA-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-8672:
------------------------------------
Labels: CAS LWT (was: CAS)
> Ambiguous WriteTimeoutException while completing pending CAS commits
> --------------------------------------------------------------------
>
> Key: CASSANDRA-8672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8672
> Project: Cassandra
> Issue Type: Bug
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Priority: Minor
> Labels: CAS, LWT
> Fix For: 2.0.15, 2.1.5
>
> Attachments: storyproxybean-2.0-8672.txt, storyproxybean-2.1-8672.txt
>
>
> Any CAS update has a chance to trigger a pending/stalled commit of any previously agreed on CAS update. After completing the pending commit, the CAS operation will resume to execute the actual update and also possibly create a new commit. See StorageProxy.cas()
> Theres two possbile execution paths that might end up throwing a WriteTimeoutException:
> cas() -> beginAndRepairPaxos() -> commitPaxos()
> cas() -> commitPaxos()
> Unfortunatelly clients catching a WriteTimeoutException won't be able to tell at which stage the commit failed. My guess would be that most developers are not aware that the beginAndRepairPaxos() could also trigger a write and assume that write timeouts would refer to a timeout while writting the actual CAS update. Its therefor not safe to assume that successive CAS or SERIAL read operations will cause a (write-)timeouted CAS operation to get eventually applied. Although some [best-practices advise|http://www.datastax.com/dev/blog/cassandra-error-handling-done-right] claims otherwise.
> At this point the safest bet is possibly to retry the complete business transaction in case of an WriteTimeoutException. However, as theres a chance that the timeout occurred while writing the actual CAS operation, another write could potentially complete it and our CAS condition will get a different result upon retry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org