Nikita Amelchev created IGNITE-29238:
----------------------------------------
Summary: Fix explicit lock candidates leaked by a timed out lock
future on a near cache
Key: IGNITE-29238
URL: https://issues.apache.org/jira/browse/IGNITE-29238
Project: Ignite
Issue Type: Bug
Reporter: Nikita Amelchev
On a cache with a near cache, the timeout of
{{IgniteCache.lock(key).tryLock(timeout)}} can expire while
{{GridNearLockFuture}} is still mapping the keys: after a GC pause longer than
the timeout, or while the mapping waits for an exchange. The timeout releases
only the candidates it finds, so what the mapping registers after that is never
released:
* a candidate added to the explicit lock span of the thread stays there as a
phantom, and the next partition map exchange on the node waits for it forever;
* for a key already held by the thread (for example {{lockAll}} with one of the
keys held), the reentry in the near entry survives the failed attempt, so the
following {{unlock()}} releases the reentry instead of the lock and the key
stays locked forever.
The same problem for caches without a near cache
({{GridDhtColocatedLockFuture}}) is IGNITE-29233
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
