Dear XWiki/xclams Devs, As you can see we have gathered more information and the clustering bug we are seeing clearly _not_ a configuration issue. We would like to have one of you verify the following test case is not an issue in the XWiki core (However I fear it might be.) We have verified the test case fails in both our development and production environments. The bug seems to be that some element of the cache is not updated, but only in one direction (When working in a two node cluster).
Here is the reproducible issue in our environments: We have two servers (S1) and (S2). Create a document on S1, then view that document on S2 and then edit it on S2 (Change the title) then view it again (refresh) on S1- Title change is not displayed. Now if you reverse the order of the servers, create on S2 then edit on S1, then view/refresh on S2, the bug does not occur! As you can see from this picture of the history version compare (http://direct.hoplahup.net/tmp/sss-history.pdf) from S1, the document in S1 is updated by the change on S2, but the title is NOT updated in the display. (Please note in the picture: the page was created on S1 with title "SSS" as version 1.1 then edited on S2 to be "SSSw" in V2.1. The history for the document on S1 shows the correct version number, and the change of the title in the comparison, but that changed title is not present in the content itself from the cached version on S1.) I do not see how this can be a configuration issue, as the cache change message is getting from S2 to S1. Neither can we see how this is a Curriki/XClams specific issue. To validate this (Or invalidate this) as a real core bug you need two servers in a cluster (S1 and S2.) Start with create on S1, edit title on S2, then refresh on S1. Then do the other way around and create a document on S2, edit the title on S1, then refresh on S2. Did you see the title update on refresh on both servers, or did one fail? Joshua Marks CTO Curriki: The Global Education and Learning Community [email protected] www.curriki.org US 831-685-3511 I welcome you to become a member of the Curriki community, to follow us on Twitter and to say hello on our blog, Facebook and LinkedIn communities. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Libbrecht Sent: Tuesday, September 18, 2012 3:08 PM To: XWiki Developers Subject: Re: [xwiki-devs] dyssmetric cluster... what's up? So I went as far as the following: - compare the configuration: they only differ in the hostnames as expetd - compare the output of the JMX JGroups' attribute-values with a diff tool. A few numbers are different... but I do not think that this is important. I then finally activated debug using logback.xml and reproduced the very simple: - create doc Sandbox.A on node 1 - verify it is visible in node 2 - edit it there (e.g. adding a letter in the title), save - fail to see the changed title in node 1 As I indicated by the "dissymetric" subject of the mail: in our two pairs of clustered servers, this only happens when node 1 and node 2 are very precise machines and it does not happen if you exchange machine 1 and machine 2. In the log I saw that the message was received but, apparently, something prevented that arrival from actually happening. What could prevent this arrival to propagate? thanks in adnvance Le 18 sept. 2012 à 19:30, Joshua Marks a écrit : > Also any input on how to debug is greatly appreciated. > -----Original Message----- > Paul Libbrecht > To: XWiki Developers > Subject: [xwiki-devs] dyssmetric cluster... what's up? > > > Hello devs, > > we are having a very very weird bug: the two nodes of our cluster are > made of A and B and saved objects sync into B when written on A but > fail to do sync into A when written on B. > > What could be the cause? > > thanks in advance _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
