You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexander Menshikov (JIRA)" <ji...@apache.org> on 2017/09/04 11:37:01 UTC
[jira] [Issue Comment Deleted] (IGNITE-4908) Ignite.reentrantLock
looks much slower than IgniteCache.lock.
[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Menshikov updated IGNITE-4908:
----------------------------------------
Comment: was deleted
(was: May be Later I will look at our lock implementations. Right now I wrote benchmark IgniteCache.lock(...) vs Ignite.reentrantLock(...). There are results:
//Ignite.reentrantLock(...)
Benchmark (create) (failoverSafe) (fair) Mode Cnt Score Error Units
JmhCacheLocksBenchmark.testIgniteLocks true true true thrpt 10 873,775 ± 60,388 ops/s
JmhCacheLocksBenchmark.testIgniteLocks true true false thrpt 10 1177,804 ± 162,082 ops/s
JmhCacheLocksBenchmark.testIgniteLocks true false true thrpt 10 915,579 ± 42,631 ops/s
JmhCacheLocksBenchmark.testIgniteLocks true false false thrpt 10 1176,044 ± 108,950 ops/s
JmhCacheLocksBenchmark.testIgniteLocks false true true thrpt 10 926,890 ± 37,080 ops/s
JmhCacheLocksBenchmark.testIgniteLocks false true false thrpt 10 1195,663 ± 73,578 ops/s
JmhCacheLocksBenchmark.testIgniteLocks false false true thrpt 10 903,658 ± 78,483 ops/s
JmhCacheLocksBenchmark.testIgniteLocks false false false thrpt 10 1159,586 ± 81,717 ops/s
//IgniteCache.lock(...)
Benchmark Mode Cnt Score Error Units
JmhCacheLocksBenchmark.testCacheLocks thrpt 10 8076,522 ± 786,153 ops/s
Looks like IgniteCache.lock(...) faster than Ignite.reentrantLock(...) at ~8 times.
I will investigate the reason.)
> 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
> Fix For: 2.3
>
>
> 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)