[
https://issues.apache.org/jira/browse/IGNITE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392365#comment-15392365
]
Eduard Shangareev edited comment on IGNITE-3513 at 7/25/16 5:43 PM:
--------------------------------------------------------------------
I have some thoughts about how to resolve this issue.
I have written this
[benchmark|https://gist.github.com/EdShangGG/9152d7273f9b92049861ab2e96c74d81].
Results (ops/us) :
||Threads||Park||Unpark||Wait||Notify||
|2|2.404|3.762|0.013|5.627|
|4|2.054|3.579|0.005|5.816|
|8|1.400|3.545|0.001|6.140|
|16|0.645|4.736|0.001|5.899|
|32|0.310|5.299|10⁻⁴|6.226|
|64|0.145|5.592|10⁻⁵|6.138|
Also, I have measured cost of {{ConcurrentSkipListSet}} invocations. It's cheap
enough, lower than 1 us even in high contended mode (32 threads).
||Solution||Pros||Cons||
|{{wait/notify}}|- better performance than {{park/unpark}}
* no extra cost in comparision with {{sleep}}|- delay between adding/updating
entry and its handling can be more that tens of milliseconde in high-contented
mode
* some slow down of adding entry in comparision with {{sleep}}|
|{{park/unpark}}|- low delay between adding/updating entry and its handling (up
to tens of microsecond
* no extra cost in comparision with {{sleep}}|- some slow down of adding entry
in comparision with {{sleep}}
- worse performance than {{wait/notify}}|
|{{sleep}}| * no slow donw of adding entry |- extra work (will check
periodically independent on data)
* millisecond resolution between checks|
[~agura], please, take a look. Can you suggest which solution we should
realize?
was (Author: edshanggg):
I have some thoughts about how to resolve this issue.
I have written this
[benchmark|https://gist.github.com/EdShangGG/9152d7273f9b92049861ab2e96c74d81].
Results (ops/us) :
||Thread||Park||Unpark||Wait||Notify||
|2|2.404|3.762|0.013|5.627|
|4|2.054|3.579|0.005|5.816|
|8|1.400|3.545|0.001|6.140|
|16|0.645|4.736|0.001|5.899|
|32|0.310|5.299|10⁻⁴|6.226|
|64|0.145|5.592|10⁻⁵|6.138|
Also, I have measured cost of {{ConcurrentSkipListSet}} invocations. It's cheap
enough, lower than 1 us even in high contended mode (32 threads).
||Solution||Pros||Cons||
|{{wait/notify}}|- better performance than {{park/unpark}}
* no extra cost in comparision with {{sleep}}|- delay between adding/updating
entry and its handling can be more that tens of milliseconde in high-contented
mode
* some slow down of adding entry in comparision with {{sleep}}|
|{{park/unpark}}|- low delay between adding/updating entry and its handling (up
to tens of microsecond
* no extra cost in comparision with {{sleep}}|- some slow down of adding entry
in comparision with {{sleep}}
- worse performance than {{wait/notify}}|
|{{sleep}}| * no slow donw of adding entry |- extra work (will check
periodically independent on data)
* millisecond resolution between checks|
[~agura], please, take a look. Can you suggest which solution we should
realize?
> Cleanup worker is placed in the Thread's waiting queue using Thread.sleep
> method
> --------------------------------------------------------------------------------
>
> Key: IGNITE-3513
> URL: https://issues.apache.org/jira/browse/IGNITE-3513
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 1.6
> Reporter: Denis Magda
> Assignee: Eduard Shangareev
> Fix For: 1.7
>
>
> There is a bug in current implementation of
> {{GridCacheTtlManager#CleanupWorker}}.
> Refer to the implementation's code snippet and the details below.
> {code}
> EntryWrapper first = pendingEntries.firstx();
> if (first != null) {
> long waitTime = first.expireTime - U.currentTimeMillis();
> if (waitTime > 0)
> U.sleep(waitTime);
> }
> {code}
> 1. Put first item with TTL = 1 hour. CleanupWorker will go to sleep for 1
> hour.
> 2. Put second item with TTL = 1 minute. Since
> CleanupWorker's thread sleeps now, second item will not be expired at the
> time.
> NOTE: This scenario is easily to reproducible if first and second items are
> put into cache asynchronously. If try to put them in same thread one-by-one
> expiration may work fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
