Thanks for the detailed report Joshua, I will try to look at it this week. On Wed, Sep 19, 2012 at 1:22 AM, Joshua Marks <[email protected]> wrote: > 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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
