[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985029#comment-16985029
]
Stefan Podkowinski commented on CASSANDRA-15350:
------------------------------------------------
Just want to add some quick notes here.
First of all, the naming for {{CasWriteUncertaintyException}} could be slightly
confusing to users, since it doesn't tell you what exactly is uncertain. Also
there are situations where the write could be "uncertain" without receiving
such an exception, e.g. when the exception could not be successfully delivered
to the client and you get a client timeout instead.
How about renaming it to something like {{CasWriteStalledException}} instead?
>From the protocol change:
"_CAS_UNCERTAINTY: An exception during contended Compare And Set write/update.
The exception indicates the CAS operation result may or may not be sucessful.
Clients receiving the exception can send a read query to confirm._"
First of all, I'm not fully sure why you would want to read, instead of just
re-issuing the cas write in that case. Maybe we can change the phrasing to
something along the line of "_write was only partially completed and operation
may or may not get completed by a following CAS write or SERIAL/LOCAL_SERIAL
read_".
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> ---------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
> Reporter: Alex Petrov
> Assignee: Yifan Cai
> Priority: Normal
> Labels: protocolv5, pull-request-available
> Attachments: Utf8StringEncodeBench.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as
> WriteTimeout. One of this conditions it manifests is when there’s at least
> one acceptor that has accepted the value, which means that this value _may_
> still get accepted during the later round, despite the proposer failure.
> Similar problem happens with CAS contention, which is also indistinguishable
> from the “regular” timeout, even though it is visible in metrics correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
