[
https://issues.apache.org/jira/browse/CASSANDRA-20691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138423#comment-18138423
]
Yuqi Yan commented on CASSANDRA-20691:
--------------------------------------
I came back to this ticket and noticed that the same fix is missing in 5.0 as
well.
In 6.0/trunk the RequestTime it should use the RequestTime#computeDeadline -
baseTimeNanos is a configurable thing and this should behave the same as the
rest I think.
I created the patches for 4.1/5.0/6.0/trunk for this. Could you help review
this? [~dcapwell] / [~ifesdjeen] thanks!
4.1: [https://github.com/apache/cassandra/pull/4187]
5.0: [https://github.com/apache/cassandra/pull/5368]
6.0: [https://github.com/apache/cassandra/pull/5369]
trunk: [https://github.com/apache/cassandra/pull/5370]
> Transport queue timeout is not applied to Paxos v2 LWT
> ------------------------------------------------------
>
> Key: CASSANDRA-20691
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20691
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Reporter: Yuqi Yan
> Assignee: Yuqi Yan
> Priority: Normal
> Fix For: 4.1.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> [https://issues.apache.org/jira/browse/CASSANDRA-19534]
> The goal of
> [CASSANDRA-19534|https://issues.apache.org/jira/browse/CASSANDRA-19534] was
> to apply request timeouts based on the task's enqueue or receive time, rather
> than starting the timeout clock only after the task is dequeued for
> processing.
> {code:java}
> public static RowIterator cas(DecoratedKey key,
> CASRequest request,
> ConsistencyLevel consistencyForConsensus,
> ConsistencyLevel consistencyForCommit,
> ClientState clientState)
> throws UnavailableException, IsBootstrappingException,
> RequestFailureException, RequestTimeoutException, InvalidRequestException
> {
> final long start = nanoTime();
> ^^^^
> final long proposeDeadline = start +
> getCasContentionTimeout(NANOSECONDS);
> final long commitDeadline = Math.max(proposeDeadline, start +
> getWriteRpcTimeout(NANOSECONDS));
> return cas(key, request, consistencyForConsensus,
> consistencyForCommit, clientState, start, proposeDeadline, commitDeadline);
> } {code}
> It appears that the LWT path for Paxos v2 was missed in the current branch.
> As a result, timeouts for LWTs may still be measured from the point of
> dequeuing, which can lead to inconsistent or delayed timeout behavior under
> high load.
> I have a patch ready and will share shortly
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
