[
https://issues.apache.org/jira/browse/CASSANDRA-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8672.
-----------------------------------------
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.1.5
2.0.15
Reviewer: Sylvain Lebresne
Assignee: Stefan Podkowinski (was: Tyler Hobbs)
> Ambiguous WriteTimeoutException while completing pending CAS commits
> --------------------------------------------------------------------
>
> Key: CASSANDRA-8672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8672
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Priority: Minor
> Labels: CAS
> 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
(v6.3.4#6332)
