[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

["Alexander Menshikov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185849#comment-16185849 ] 

Alexander Menshikov commented on IGNITE-4908:
---------------------------------------------

[~amashenkov] [~avinogradov]
I’ve researched the current implementation of Ignite reentrantlock. The main problem with original Ignite reentrant lock is using a continuous query which parses every update operation. Even if we decrease time of the operation execution, lock will degrade quadratically to the nodes count anyway only because of a continuous query. Another problem is using transactions for update shared state (avoid transactions is the way for decrease time).

I’ve already fixed both problems in the new implementation of the reentrant lock. I’ve added a new release message to avoid using the continuous query. Also, I have used IgniteCache#invoke to avoid using transactions. It has given me 4.5 times speedup.

But IgniteCache#lock still works 2 times faster than improved Ignite#reentrantLock, because IgniteCache#lock doesn't make any operation on a cache, unlike Ignite#reentrantLock. I mean any operation with atomic IgniteCache takes the same time as calling of the lock+unlock of Cache Lock, in addition, we need 2 such operations: first to lock, second to unlock.

Most of the time used on messaging. IgniteCache#lock sends about 1K bytes per lock+unlock, at the same time 2 calls of IgniteCache#invoke send about 3K bytes in sum (checks on a cluster with 10 nodes, but on the same JVM).

> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -------------------------------------------------------------
>
>                 Key: IGNITE-4908
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4908
>             Project: Ignite
>          Issue Type: Improvement
>          Components: data structures
>    Affects Versions: 1.8
>            Reporter: Andrew Mashenkov
>            Assignee: Alexander Menshikov
>
> Design discussed with Alexander:
> 1) Lock 
> Entry Processor (sync) -> 
> ....add candidate. 
> ....returns "added candidate at first position"
> ....retry failover -> 
> ........if already at first position -> return true
> In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer should be used).
> 2) Unlock 
> Entry Processor (async) -> 
> ....remove candidate at first position
> ....retry failover -> remove only if "candidate at first position" equals to expected
> ....listener ->
> ........notify current "candidate at first position" it got lock
> 3)Failover
> 3.1) Originating node failed
> Failed node listener ->
> ....For each local(primary) lock ->
> ........Entry Processor (async) ->
> ............remove candidates related no failed node
> ............retry failover not needed
> ............listener -> 
> ................if "candidate at first position" removed ->
> ....................notify current "candidate at first position" it got lock
> 3.2) Primary node failed
> After rebalancing schedule Callable ->
> ....For each local(primary) lock ->
> ........Entry Processor (async) ->
> ............remove candidates related to failed nodes
> ............retry failover not needed
> ............listener -> 
> ................notify current "candidate at first position" it got lock



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)