Re: [xwiki-devs] [xwiki-notifications] r15898 - enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/xwiki/xmlrpc
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()); }
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)
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
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)
participants (2)
-
Fabio Mancinelli -
Vincent Massol