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)