[
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)
