[
https://issues.apache.org/jira/browse/IGNITE-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9506:
-----------------------------------
Attachment: TimeoutBugReproducer.java
> Timeout object with mutable end time breaks GridTimeoutProcessor behavior
> -------------------------------------------------------------------------
>
> Key: IGNITE-9506
> URL: https://issues.apache.org/jira/browse/IGNITE-9506
> Project: Ignite
> Issue Type: Bug
> Components: cache
> 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)
> It sounds good idea to prohibit adding objects with mutable end time to the
> timeout queue, e.g. read end time when adding to the queue and copy for
> internal usage by timeout processor. Unfortunately, it seems impossible to do
> it right away because existing API could be broken (like mentioned
> transactions with timeout setter).
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
