[jira] [Updated] (IGNITE-9506) Timeout object with mutable end time breaks GridTimeoutProcessor behavior

["Ivan Pavlukhin (JIRA)" <ji...@apache.org>]

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

Ivan Pavlukhin updated IGNITE-9506:
-----------------------------------
    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)
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.

  was:
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.SECONDS.toMillis(10));
    ...
}{code}


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