[ https://issues.apache.org/jira/browse/IGNITE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392365#comment-15392365 ]
Eduard Shangareev commented on IGNITE-3513: ------------------------------------------- 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)