Re: [xwiki-devs] [xwiki-notifications] r15898 - enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/xwiki/xmlrpc
30 Jan
2009
30 Jan
'09
1:09 p.m.
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
+
XWikiPage page = this.rpc.getPage(pages.get(0).getId());
+ System.out.format("Modifying: %s\n", page);
+
page.setContent(String.format("Modified %d",
System.currentTimeMillis()));
page = rpc.storePage(page);
- List<XWikiPageHistorySummary> modifications =
rpc.getModifiedPagesHistory(1, 0);
+ System.out.format("Modified: %s\n", page);
+ List<XWikiPageHistorySummary> modifications =
rpc.getModifiedPagesHistory(3, 0);
+
+ System.out.format("Modifications:\n");
+ for (XWikiPageHistorySummary modification : modifications) {
+ System.out.format("%s\n", modification);
+ }
+
assertEquals(page.getId(),
modifications.get(0).getBasePageId());
assertEquals(page.getModified(),
modifications.get(0).getModified());
}
30 Jan
30 Jan
1:45 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r15898 - enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/xwiki/xmlrpc
On Jan 30, 2009, at 1:09 PM, Vincent Massol wrote:
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.
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)
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
>
1:59 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r15898 - enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/xwiki/xmlrpc
On Jan 30, 2009, at 1:45 PM, Fabio Mancinelli wrote:
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)
Ok. A rapid look at XMLRPC data types (http://ws.apache.org/xmlrpc/types.html
) shows that dates transfered via XMLRPC miss milliseconds and
timezone information. We are not using extended types so from this
point of view we are stuck.
In order to avoid timers, I can switch back to the solution where I
download a bigger modification list and check that the page modified
in the test is there.
Cheers,
Fabio
5:05 p.m.
New subject: [xwiki-devs] [xwiki-notifications] r15898 - enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/xwiki/xmlrpc
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)
5708
days inactive
5708
days old
3 comments
2 participants
participants (2)
-
Fabio Mancinelli -
Vincent Massol