Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Tue, 18 Mar 2014 14:02:23 +0000 (UTC)
From: "Dominique Pfister (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12700687.1394541575496.96960.1395151343166@arcas>
In-Reply-To: <JIRA.12700687.1394541575496@arcas>
References: <JIRA.12700687.1394541575496@arcas>
Subject: [jira] [Comment Edited] (JCR-3743) failing test if aws extensions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939210#comment-13939210 ] 

Dominique Pfister edited comment on JCR-3743 at 3/18/14 2:01 PM:
-----------------------------------------------------------------

bq. You'll have to check the code for any assumptions of System.currentTimeMillis having a better granularity than 20ms. For instance, the assert on getLastModified being > updateTime looks fishy.

The test fails since {{rec1}}'s last modified time hasn't effectively changed, although the record was accessed and touched some lines _after_ updateModifiedDateOnAccess() was called:
{code}
Thread.sleep(2000);
long updateTime = System.currentTimeMillis();
ds.updateModifiedDateOnAccess(updateTime);

data = new byte[dataLength];
random.nextBytes(data);
DataRecord rec3 = ds.addRecord(new ByteArrayInputStream(data));

data = new byte[dataLength];
random.nextBytes(data);
DataRecord rec4 = ds.addRecord(new ByteArrayInputStream(data));

rec1 = ds.getRecord(rec1.getIdentifier());
{code}

So your reasoning implies that adding the 2 DataRecords {{rec3}} and {{rec4}} takes less than 20ms? If this would be the case, I'd split the sleep of 2000 ms into two sleeps of 1000 ms each, and have the second one put after obtaining the {{updateTime}} above.


was (Author: dpfister):
bq. You'll have to check the code for any assumptions of System.currentTimeMillis having a better granularity than 20ms. For instance, the assert on getLastModified being > updateTime looks fishy.

The test fails since {{rec1}}'s last modified time hasn't been updated, although the record was accessed some lines _after_ updateModifiedDateOnAccess() was called:
{code}
Thread.sleep(2000);
long updateTime = System.currentTimeMillis();
ds.updateModifiedDateOnAccess(updateTime);

data = new byte[dataLength];
random.nextBytes(data);
DataRecord rec3 = ds.addRecord(new ByteArrayInputStream(data));

data = new byte[dataLength];
random.nextBytes(data);
DataRecord rec4 = ds.addRecord(new ByteArrayInputStream(data));

rec1 = ds.getRecord(rec1.getIdentifier());
{code}

So your reasoning implies that adding the 2 DataRecords {{rec3}} and {{rec4}} takes less than 20ms? If this would be the case, I'd split the sleep of 2000 ms into two sleeps of 1000 ms each, and have the second one put after obtaining the {{updateTime}} above.

> failing test if aws extensions
> ------------------------------
>
>                 Key: JCR-3743
>                 URL: https://issues.apache.org/jira/browse/JCR-3743
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>            Reporter: Julian Reschke
>            Assignee: Dominique Pfister
>            Priority: Minor
>
> On Win7/64bit/corei7:
> Failed tests:
>   testDeleteAllOlderThan(org.apache.jackrabbit.aws.ext.ds.TestInMemDs)
>   testDeleteAllOlderThan(org.apache.jackrabbit.aws.ext.ds.TestInMemDsCacheOff)
> Likely because of incorrect assumptions about System.currentTimeMillis()


--
This message was sent by Atlassian JIRA
(v6.2#6252)