[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986687#comment-16986687 ]
Alex Petrov commented on CASSANDRA-15350: ----------------------------------------- To be honest, I think the fact that names {{WriteStalled}} and {{WriteTimeout}} are quite close to each other might confuse the user. We need to reflect the fact that it's a Paxos round failure or that the reason is that _we do not know_ whether the value is going to go through or not. bq. ErrorMessage is not involved in internode messageing Err; of course. Sorry about that: was thinking in a different context and phrased it wrong. Also, both messages occur on the coordinator, so internode doesn't apply. What I should have written is that this logic is used by the {{SimpleClient}}. bq. the scenario was carefully crafted to be deterministic and aims to produce the same kind of contention. This is precisely what I'm concerned about: it is carefully crafted and might be difficult to maintain. Everyone who'll be modifying the code in the future will have to re-craft the test as well. I think we can relatively easily reproduce it with a fuzz test that introduces contention. I think introducing latency/partition in the test is a reasonable thing, I'd just make it random rather than handcrafted. This will also help us to see how it all behaves when contention is higher. bq. Do you mean rename the method to activate/deactivate, Right, I'd just call them {{activate}} and {{deactivate}}. We also need at least a version of the {{SimpleClient}} to be tested with the changes. Ideally, we need an accompanying patch for the java-driver, since it changes the native protocol. > 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