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