Mailing-List: contact issues-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Date: Mon, 25 Jul 2016 17:44:20 +0000 (UTC)
From: "Eduard Shangareev (JIRA)" <jira@apache.org>
To: issues@ignite.apache.org
Message-ID: <JIRA.12991083.1469011474000.125642.1469468660486@Atlassian.JIRA>
In-Reply-To: <JIRA.12991083.1469011474000@Atlassian.JIRA>
References: <JIRA.12991083.1469011474000@Atlassian.JIRA> <JIRA.12991083.1469011474918@arcas>
Subject: [jira] [Comment Edited] (IGNITE-3513) Cleanup worker is placed in
 the Thread's waiting queue using Thread.sleep method
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 25 Jul 2016 17:44:22 -0000


    [ https://issues.apache.org/jira/browse/IGNITE-3513?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D153=
92365#comment-15392365 ]=20

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/9152d7273f=
9b92049861ab2e96c74d81].

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=E2=81=BB=E2=81=B4|6.226|
|64|0.145|5.592|10=E2=81=BB=E2=81=B5|6.138|

Also, I have measured cost of {{ConcurrentSkipListSet}} invocations. It's c=
heap 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/updati=
ng entry and its handling can be more that tens of milliseconde in high-con=
tented mode=20
* 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 en=
try in comparision with {{sleep}}
-  worse performance than {{wait/notify}}|
|{{sleep}}| * no slow donw of adding entry |- extra work (will check period=
ically independent on data)
* millisecond resolution between checks|

[~agura], please, take a look. Can you suggest which solution we should rea=
lize?=20


was (Author: edshanggg):
I have some thoughts about how to resolve this issue.

I have written this [benchmark|https://gist.github.com/EdShangGG/9152d7273f=
9b92049861ab2e96c74d81].

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=E2=81=BB=E2=81=B4|6.226|
|64|0.145|5.592|10=E2=81=BB=E2=81=B5|6.138|

Also, I have measured cost of {{ConcurrentSkipListSet}} invocations. It's c=
heap 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/updati=
ng entry and its handling can be more that tens of milliseconde in high-con=
tented mode=20
* 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 en=
try in comparision with {{sleep}}
-  worse performance than {{wait/notify}}|
|{{sleep}}| * no slow donw of adding entry |- extra work (will check period=
ically independent on data)
* millisecond resolution between checks|

[~agura], please, take a look. Can you suggest which solution we should rea=
lize?=20

> 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#Cleanup=
Worker}}.
> Refer to the implementation's code snippet and the details below.
> {code}
> EntryWrapper first =3D pendingEntries.firstx();
>  if (first !=3D null) {
>    long waitTime =3D first.expireTime - U.currentTimeMillis();
>    if (waitTime > 0)
>       U.sleep(waitTime);
>  }
> {code}
> 1. Put first item with TTL =3D 1 hour. CleanupWorker will go to sleep for=
 1 hour.
> 2. Put second item with TTL =3D 1 minute. Since=20
> 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 a=
re 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)