[
https://issues.apache.org/jira/browse/IGNITE-20157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20157:
----------------------------------
Description:
*Motivation*
On client side, we have only "Replication timeout exception" happening on
request timeout, and we can't know the exact reason without debugging. Later it
will be replaced with transaction timeout exception, but this would not solve
the problem. We should know somehow what happened on the server side. Timeouts
should be set on operations on primary replica side that are most likely the
cause of request timeouts. In case of such operation timeout on promary
replica, a corresponding exception should be printed to the log, so that it can
be matched with an exception on client by transaction id.
*Definition of done*
Future returned by LockManager#acquire is completed exceptionally if the lock
was not acquired in some time interval (lock acquisition timeout).
*Implementation notes*
This exception (or its message) should differ from the exception thrown because
of deadlock prevention policy with timeout.
was:
*Motivation*
Currently we have lock timeouts only for specific implementations of
DeadlockPreventionPolicy. In the same time, we have transaction request
timeouts. It makes no sense for such requests to wait for acquiring locks
longer than request timeout.
*Definition of done*
Future returned by LockManager#acquire is completed exceptionally if the lock
was not acquired in some time interval (lock acquisition timeout).
*Implementation notes*
This exception (or its message) should differ from the exception thrown because
of deadlock prevention policy with timeout.
> Share context details to ease replication timeout exception analysis
> --------------------------------------------------------------------
>
> Key: IGNITE-20157
> URL: https://issues.apache.org/jira/browse/IGNITE-20157
> Project: Ignite
> Issue Type: Improvement
> Reporter: Denis Chudov
> Priority: Major
> Labels: ignite-3
>
> *Motivation*
> On client side, we have only "Replication timeout exception" happening on
> request timeout, and we can't know the exact reason without debugging. Later
> it will be replaced with transaction timeout exception, but this would not
> solve the problem. We should know somehow what happened on the server side.
> Timeouts should be set on operations on primary replica side that are most
> likely the cause of request timeouts. In case of such operation timeout on
> promary replica, a corresponding exception should be printed to the log, so
> that it can be matched with an exception on client by transaction id.
> *Definition of done*
> Future returned by LockManager#acquire is completed exceptionally if the lock
> was not acquired in some time interval (lock acquisition timeout).
> *Implementation notes*
> This exception (or its message) should differ from the exception thrown
> because of deadlock prevention policy with timeout.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
