30 Jan
2009
30 Jan
'09
5:05 p.m.
On Jan 30, 2009, at 1:45 PM, Fabio Mancinelli wrote:
On Jan 30, 2009, at 1:09 PM, Vincent Massol wrote:
Yes I meant modifying the modification date. I haven't checked if
that's possible or not though.
On Jan 30, 2009, at 12:37 PM, fmancinelli (SVN) wrote:
I don't understand what do you mean by "changing the date". The date
is that assigned by the server to the modification. 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
>
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)