On Jan 30, 2009, at 1:45 PM, Fabio Mancinelli wrote:
>
> 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.
Yes I meant modifying the modification date. I haven't checked if
that's possible or not though.
>
> 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?
They're bad for 2 reasons:
1) They make the application slower than it should be.
2) You cannot easily choose the time to wait since it depends on the
OS (some are faster, other are slower).
3) they're always a hack around a design issue IMO
Thanks
-Vincent
>
>
> -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
