[jira] [Assigned] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior

["Alexei Scherbakov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexei Scherbakov reassigned IGNITE-9602:
-----------------------------------------

    Assignee: Alexei Scherbakov

> Transaction timeout setter could break GridTimeoutProcessor behavior
> --------------------------------------------------------------------
>
>                 Key: IGNITE-9602
>                 URL: https://issues.apache.org/jira/browse/IGNITE-9602
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: 2.7
>            Reporter: Ivan Pavlukhin
>            Assignee: Alexei Scherbakov
>            Priority: Major
>         Attachments: TimeoutBugReproducer.java
>
>
> Current transaction API provides setter method for transaction timeout. It is possible to run transaction as follows:
> {code:java}
> try (Transaction tx = ign.transactions().txStart()) {
>     tx.timeout(TimeUnit.MINUTES.toMillis(10));
>     ...
> }
> {code}
> If default timeout is configured to smaller timeout value then it is possible that transaction will be added to the head of timeout queue. Changing timeout after that to some big number will lead to situation when head of timeout queue contains not smallest timeout end time value, totally breaking invariant of that queue. It could lead to a different negative consequences. From delaying other tasks in timeout processor until mentioned transaction completes or timeouts to completely stalling timeout processor progress (broken queue invariant could lead to impossibility to remove objects from it). (java.util.concurrent.ConcurrentSkipListMap is used under the hood of the timeout queue)
> Actually {{GridNearTxLocal.timeout}} setter tries to reset timeout but does it improperly. It looks like that behavior was broken not long ago.
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)