On Jan 30, 2009, at 1:09 PM, Vincent Massol wrote:
>
> On Jan 30, 2009, at 12:37 PM, fmancinelli (SVN) wrote:
>
>> Author: fmancinelli
>> Date: 2009-01-30 12:37:35 +0100 (Fri, 30 Jan 2009)
>> New Revision: 15898
>>
>> Modified:
>> enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/
>> xwiki/xmlrpc/PagesTest.java
>> Log:
>> [Minor] Fixed a stability bug of the page history test.
>>
>> The problem was due to the fact that if pages are stored too fast,
>> they will have the same timestamp in the modification list (the
>> granularity is 1 sec.) and they will be returned in an arbitrary
>> order (depending on the server side query result).
>>
>> This means that the modified page in the test, even if it's present
>> in the modification list, could not be returned as the first item of
>> that list, causing the assertion to fail.
>>
>> The solution was to wait 2 seconds before storing the page. This
>> will guarantee that the timestamp will surely be different from any
>> previous modification (and that the page will be on the top of the
>> list if things work well)
>>
>> Modified: enterprise/trunk/distribution-test/xmlrpc-tests/src/test/
>> it/org/xwiki/xmlrpc/PagesTest.java
>> ===================================================================
>> --- enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/
>> xwiki/xmlrpc/PagesTest.java 2009-01-30 10:27:52 UTC (rev 15897)
>> +++ enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/
>> xwiki/xmlrpc/PagesTest.java 2009-01-30 11:37:35 UTC (rev 15898)
>> @@ -663,13 +663,33 @@
>>
>> TestUtils.banner("TEST:
>> getAllModifiedPageHistoryCorrectness()");
>>
>> + /*
>> + * Wait 2 seconds before making the modification. This is
>> necessary because if pages are stored in the same
>> + * second, they will have the same timestamp and they could
>> be returned in an arbitrary order making the
>> + * following assert fail randomly
>> + */
>> + try {
>> + Thread.sleep(2000);
>> + } catch (InterruptedException e) {
>> +
>> + }
>
> ouch this is bad... We need to find a better way IMO, like changing
> the date and adding 1 second after it's stored or something but not
> using timers.
>
> -Vincent
>>
I don't understand what do you mean by "changing the date". The date
is that assigned by the server to the modification.
Otherwise I can simply check that the change exist in the first N
modification (where N is big enough, like 20).
Btw, why timers are so bad?
-Fabio
P.S.: Actually I don't know where the 1 sec. granularity comes from,
but I suspect that's XMLRPC that has a standard encoding for dates
that ignores milliseconds, so when dates are serialized they are
rounded. I will investigate if there's a way for configuring XMLRPC in
a way that it doesn't ignore milliseconds. That would also solve the
issue (and the test could be also reverted to its previous form)
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
