[
https://issues.apache.org/jira/browse/IGNITE-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9602:
-----------------------------------
Description:
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 it looks like {{GridNearTxLocal.timeout}} setter tries to do timeout
reset properly but does it improperly.
Reproducer is attached.
> 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
> 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 it looks like {{GridNearTxLocal.timeout}} setter tries to do timeout
> reset properly but does it improperly.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
