ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eduard Shangareev (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-3513) Cleanup worker is placed in the Thread's waiting queue using Thread.sleep method
Date Mon, 25 Jul 2016 17:44:20 GMT

    [ 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)

Mime
View raw message