[
https://issues.apache.org/jira/browse/CASSANDRA-20691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Yan updated CASSANDRA-20691:
---------------------------------
Description:
https://issues.apache.org/jira/browse/CASSANDRA-19534
The goal of the ticket 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
was:
https://issues.apache.org/jira/browse/CASSANDRA-19534
The goal of the ticket 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.
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
> 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
> Reporter: Yuqi Yan
> Assignee: Yuqi Yan
> Priority: Normal
>
> https://issues.apache.org/jira/browse/CASSANDRA-19534
> The goal of the ticket 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
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
