Re: [xwiki-devs] dyssmetric cluster... what's up?
Thank you Thomas, so it turned out an elementary configuration bit caused the test with titles to fail: the presence of a cache folder in WEB-INF containing various cache configs. Removing that made the test with titles and contents succeed. However, the test with collections still fails, and now I finally had it to fail on my sever as well: two tomcats, joined through a tcp channel, ... What I observe is that after a revision is cached in a server, a change of objects only on the other does not propagate. The event and history frame comes up, not the added object. Let me understand: jgroups just does the communication, and listeners include a cache listener which invalidate the entry when the document-event is fired. Is it correct? thanks in advance Paul
On Fri, Sep 28, 2012 at 10:03 AM, Paul Libbrecht <[email protected]> wrote:
Thank you Thomas,
so it turned out an elementary configuration bit caused the test with titles to fail: the presence of a cache folder in WEB-INF containing various cache configs. Removing that made the test with titles and contents succeed.
However, the test with collections still fails, and now I finally had it to fail on my sever as well: two tomcats, joined through a tcp channel, ... What I observe is that after a revision is cached in a server, a change of objects only on the other does not propagate. The event and history frame comes up, not the added object.
Let me understand: jgroups just does the communication, and listeners include a cache listener which invalidate the entry when the document-event is fired. Is it correct?
Yes. The first thing to make sure is to check of JGroups message go from one server to another both way, you can enable remote observation module debug log for this (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module+Remo...). There is several caches in XWiki and you maybe have several of your own so if jgroups properly send messages it mean some cache somewhere corresponding to what you are viewing is not invalidated when receiving an event. When you can reproduce the issue the idea would be to find what is the cache with the issue, it's not always easy to find out when you don't know exactly all the caches but you can view all of them using JMX (see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Monitoring#HXWikiCachesM...), at least all the caches created through standard XWiki cache module.
thanks in advance
Paul
-- Thomas Mortagne
The first thing to make sure is to check of JGroups message go from one server to another both way, you can enable remote observation module debug log for this (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module+Remo...).
Done and checked: yes it works. (all written down on http://jira.xwiki.org/browse/CURRIKI-5909)
There is several caches in XWiki and you maybe have several of your own so if jgroups properly send messages it mean some cache somewhere corresponding to what you are viewing is not invalidated when receiving an event.
Can it be it's invalidated too early? This seems to be my best guess. Then the older version is fetched from the DB.
When you can reproduce the issue the idea would be to find what is the cache with the issue, it's not always easy to find out when you don't know exactly all the caches but you can view all of them using JMX (see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Monitoring#HXWikiCachesM...), at least all the caches created through standard XWiki cache module.
Thus far, any such inconsistency, on production environments, is solved with a cache-clear so this is likely. I could find out by just emptying one or the other right? paul
On Fri, Sep 28, 2012 at 12:02 PM, Paul Libbrecht <[email protected]> wrote:
The first thing to make sure is to check of JGroups message go from one server to another both way, you can enable remote observation module debug log for this (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module+Remo...).
Done and checked: yes it works. (all written down on http://jira.xwiki.org/browse/CURRIKI-5909)
There is several caches in XWiki and you maybe have several of your own so if jgroups properly send messages it mean some cache somewhere corresponding to what you are viewing is not invalidated when receiving an event.
Can it be it's invalidated too early? This seems to be my best guess. Then the older version is fetched from the DB.
It should not, a document event for example is send after the document is saved in the database so if you react to this event you can't invalidate the cache too early. IMO there is only two possibilities here: * the listener that is supposed to invalidate the cache does not receive the event for some reason * there is no such listener or it's buggy
When you can reproduce the issue the idea would be to find what is the cache with the issue, it's not always easy to find out when you don't know exactly all the caches but you can view all of them using JMX (see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Monitoring#HXWikiCachesM...), at least all the caches created through standard XWiki cache module.
Thus far, any such inconsistency, on production environments, is solved with a cache-clear so this is likely.
I could find out by just emptying one or the other right?
Indeed.
paul
-- Thomas Mortagne
So it appears that the bug was solved by adjusting our notification listener to ignore notifications when a LazyXWikiDocument is used. This prevents the LazyXWikiDocument to be put in the cache. This does not seems documented but I seem to observe that LazyXWikiDocument is in notifications when that notification is coming from outside. Do I have another way to recognize it? thanks in advance Paul
It should not, a document event for example is send after the document is saved in the database so if you react to this event you can't invalidate the cache too early.
IMO there is only two possibilities here: * the listener that is supposed to invalidate the cache does not receive the event for some reason * there is no such listener or it's buggy
When you can reproduce the issue the idea would be to find what is the cache with the issue, it's not always easy to find out when you don't know exactly all the caches but you can view all of them using JMX (see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Monitoring#HXWikiCachesM...), at least all the caches created through standard XWiki cache module.
Thus far, any such inconsistency, on production environments, is solved with a cache-clear so this is likely.
I could find out by just emptying one or the other right?
Indeed.
paul
-- Thomas Mortagne _______________________________________________ xclams-devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/xclams-devs
On Fri, Sep 28, 2012 at 10:29 PM, Paul Libbrecht <[email protected]> wrote:
So it appears that the bug was solved by adjusting our notification listener to ignore notifications when a LazyXWikiDocument is used. This prevents the LazyXWikiDocument to be put in the cache.
This does not seems documented but I seem to observe that LazyXWikiDocument is in notifications when that notification is coming from outside. Do I have another way to recognize it?
The canonical way to check if you are called by a remote event is by using the component org.xwiki.observation.remote.RemoteObservationManagerContex#isRemoteState() (from xwiki-platform-observation-remote). LazyXWikiDocument is what is used when emulating a document event from the remote observation module. It's actually supposed to behave like a XWikiDocument except that it actually load the document from the database only if something actually need to manipulate it. The only thing for which it's not supposed to work well is if you try to save it directly but it's not recommended for a document coming in a local event anyway since it's creating an events mess. So unless you really have a specific logic that need to do different things from local and remote events the best would be that we fix what's wrong with LazyXWikiDocument in your use case.
thanks in advance
Paul
It should not, a document event for example is send after the document is saved in the database so if you react to this event you can't invalidate the cache too early.
IMO there is only two possibilities here: * the listener that is supposed to invalidate the cache does not receive the event for some reason * there is no such listener or it's buggy
When you can reproduce the issue the idea would be to find what is the cache with the issue, it's not always easy to find out when you don't know exactly all the caches but you can view all of them using JMX (see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Monitoring#HXWikiCachesM...), at least all the caches created through standard XWiki cache module.
Thus far, any such inconsistency, on production environments, is solved with a cache-clear so this is likely.
I could find out by just emptying one or the other right?
Indeed.
paul
-- Thomas Mortagne _______________________________________________ xclams-devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/xclams-devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Le 1 oct. 2012 à 09:25, Thomas Mortagne a écrit :
The canonical way to check if you are called by a remote event is by using the component org.xwiki.observation.remote.RemoteObservationManagerContex#isRemoteState() (from xwiki-platform-observation-remote).
How do I get an instance of this from Groovy?
LazyXWikiDocument is what is used when emulating a document event from the remote observation module. It's actually supposed to behave like a XWikiDocument except that it actually load the document from the database only if something actually need to manipulate it. The only thing for which it's not supposed to work well is if you try to save it directly but it's not recommended for a document coming in a local event anyway since it's creating an events mess. So unless you really have a specific logic that need to do different things from local and remote events the best would be that we fix what's wrong with LazyXWikiDocument in your use case.
It was the request of previous versions which has failed. All that seems quite curriki specific in there is a simple listener, using the old-style-notification, which analyzes the document and indexes it and maybe "related" documents (for example reindexes the user-document so as to display the count of contributions, or reindexes all of the resources of the user if the user has changed his name...). The IndexUpdater of the LucenePlugin does not seem to care for this (but then, it doesn't seem to measure differences). thanks in advance Paul
On Mon, Oct 1, 2012 at 12:04 PM, Paul Libbrecht <[email protected]> wrote:
Le 1 oct. 2012 à 09:25, Thomas Mortagne a écrit :
The canonical way to check if you are called by a remote event is by using the component org.xwiki.observation.remote.RemoteObservationManagerContex#isRemoteState() (from xwiki-platform-observation-remote).
How do I get an instance of this from Groovy?
If you know how to get a component in Groovy already you can do lookup the component with role org.xwiki.observation.remote.RemoteObservationManagerContex and default hint.
LazyXWikiDocument is what is used when emulating a document event from the remote observation module. It's actually supposed to behave like a XWikiDocument except that it actually load the document from the database only if something actually need to manipulate it. The only thing for which it's not supposed to work well is if you try to save it directly but it's not recommended for a document coming in a local event anyway since it's creating an events mess. So unless you really have a specific logic that need to do different things from local and remote events the best would be that we fix what's wrong with LazyXWikiDocument in your use case.
It was the request of previous versions which has failed.
All that seems quite curriki specific in there is a simple listener, using the old-style-notification, which analyzes the document and indexes it and maybe "related" documents (for example reindexes the user-document so as to display the count of contributions, or reindexes all of the resources of the user if the user has changed his name...). The IndexUpdater of the LucenePlugin does not seem to care for this (but then, it doesn't seem to measure differences).
What version of XWiki is that ? Actually there is several other listener that look at previous version (for example there is listener that check differences and produce more precise event about object, object properties, classes, attachments, etc.) so at least in most recent versions it's supposed to work.
thanks in advance
Paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
It was the request of previous versions which has failed.
All that seems quite curriki specific in there is a simple listener, using the old-style-notification, which analyzes the document and indexes it and maybe "related" documents (for example reindexes the user-document so as to display the count of contributions, or reindexes all of the resources of the user if the user has changed his name...). The IndexUpdater of the LucenePlugin does not seem to care for this (but then, it doesn't seem to measure differences).
What version of XWiki is that ?
3.5 with old-core and legacy-old-core.
Actually there is several other listener that look at previous version (for example there is listener that check differences and produce more precise event about object, object properties, classes, attachments, etc.) so at least in most recent versions it's supposed to work.
That was just the most recent version. We spent a few hours yesterday about it and got a little further: on our beta installation the bug did not appear while it does n our production installation it does. The only meaningful difference I found is:
28,29c26,27 < <property name="connection.pool_size">50</property> < <property name="statement_cache.size">50</property> ---
<property name="connection.pool_size">2</property> <property name="statement_cache.size">2</property>
(left is production's hibernate configuration) We did confirm on beta that the bug reappeared by changing these two parameters to 50 and disappeared when back to 2. However, when deploying on production the values 2, and restarting, the bug was still there. At this point either we can maybe: - try to automate tests more - disable clustering - get a good hint on the differences Paul
On Tue, Oct 2, 2012 at 11:10 AM, Paul Libbrecht <[email protected]> wrote:
It was the request of previous versions which has failed.
All that seems quite curriki specific in there is a simple listener, using the old-style-notification, which analyzes the document and indexes it and maybe "related" documents (for example reindexes the user-document so as to display the count of contributions, or reindexes all of the resources of the user if the user has changed his name...). The IndexUpdater of the LucenePlugin does not seem to care for this (but then, it doesn't seem to measure differences).
What version of XWiki is that ?
3.5 with old-core and legacy-old-core.
Actually there is several other listener that look at previous version (for example there is listener that check differences and produce more precise event about object, object properties, classes, attachments, etc.) so at least in most recent versions it's supposed to work.
That was just the most recent version.
We spent a few hours yesterday about it and got a little further: on our beta installation the bug did not appear while it does n our production installation it does. The only meaningful difference I found is:
28,29c26,27 < <property name="connection.pool_size">50</property> < <property name="statement_cache.size">50</property> ---
<property name="connection.pool_size">2</property> <property name="statement_cache.size">2</property>
OK will try with 50 and see what I get. Not sure how this could be related unless it makes the LazyXWikiDocument fail to get the document from the database for some weird reason.
(left is production's hibernate configuration)
We did confirm on beta that the bug reappeared by changing these two parameters to 50 and disappeared when back to 2.
However, when deploying on production the values 2, and restarting, the bug was still there.
At this point either we can maybe: - try to automate tests more - disable clustering
- get a good hint on the differences
Same database and jdbc connector versions ?
Paul
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
At this point either we can maybe: - try to automate tests more - disable clustering
- get a good hint on the differences
Same database and jdbc connector versions ?
yes: mysql-connector-java-5.1.9.jar The hibernate.cfg.xml are equal. paul
The story evolved down here. I have crafted an extra observer that listens to notifications and checks if the values are the same when in event and one second later in a spawned thread. They're not. The code is copied below, it is inspired from the nice tutorial about observation. Since about 36h, the observation listener below has reported 967 saves. From them, 145 indicate the warning at the end of this code. This warning indicates that the title, number of a objects of a particular class (where we observed the bug first), or version differ: - when pulled from the source of the event (XWikiDocument or LazyXWikiDocument) - or when pulled one second later with xwiki.getXWiki().getDocument(). However, and that's the crusty bit. Somehow, the attempt to reproduce the bug have almost all failed since that time as well. (no systematic way to reproduce the bug has been found, neither has there been a page that stayed different between the two nodes). We're on hold but this is a rather good surprise! Paul
It was the request of previous versions which has failed.
All that seems quite curriki specific in there is a simple listener, using the old-style-notification, which analyzes the document and indexes it and maybe "related" documents (for example reindexes the user-document so as to display the count of contributions, or reindexes all of the resources of the user if the user has changed his name...). The IndexUpdater of the LucenePlugin does not seem to care for this (but then, it doesn't seem to measure differences). OK will try with 50 and see what I get. Not sure how this could be related unless it makes the LazyXWikiDocument fail to get the document from the database for some weird reason.
// {{groovy}} // This page should be Util.TryObservation // import org.xwiki.observation.* import org.xwiki.observation.event.* import com.xpn.xwiki.web.* import com.xpn.xwiki.* import org.xwiki.bridge.event.DocumentUpdatedEvent import com.xpn.xwiki.doc.XWikiDocument import org.apache.commons.logging.Log import org.apache.commons.logging.LogFactory import com.xpn.xwiki.util.AbstractXWikiRunnable import org.xwiki.observation.remote.RemoteObservationManagerContext class TryObservation implements EventListener { static final Log LOG = LogFactory.getLog("groovyPages.Sandbox.TryObservation"); boolean DEBUG = LOG.isDebugEnabled(); XWiki xwiki XWikiContext xcontext TryObservation(xwiki, xcontext) { this.xwiki = xwiki this.xcontext = xcontext } String getName() { // The unique name of this event listener return "Changes-Version-Checker" } List<Event> getEvents() { // The list of events this listener listens to return Arrays.asList(new DocumentUpdatedEvent()) } // Called by the Observation Manager when an event matches the list of events returned // by getEvents() void onEvent(Event event, Object source, Object data) { XWikiDocument xdoc = source; LOG.warn("Received event: " + event + ", source: " + source); LOG.warn("Title of changed document " + xdoc.getTitle()) LOG.warn("Version of changed document " + xdoc.getVersion()) int count = 0; List o = xdoc.getObjects("CurrikiCode.SubAssetClass"); if(o!=null) count = o.size() LOG.warn("Number of children: " + count); LOG.warn("Is remote? " + Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState()); Thread obs = new Thread(new DelayedObserver(xwiki, xcontext, xdoc.getFullName(), xdoc.getTitle(), xdoc.getVersion(), count),"delayed obs"); obs.start(); LOG.warn("started obs " + obs); // Prevent infinite recursion since in this example we log to wiki page which // triggers a document change... :) /* if (source.fullName != "Sandbox.TryObservation") { def document = xwiki.getDocument("Sandbox.TryObservation") document.setContent("${document.getContent()}\n${source.fullName} has changed") document.save("Logging event", true) } */ } public static class DelayedObserver extends AbstractXWikiRunnable { public DelayedObserver(XWiki xwiki, XWikiContext context, String fullName, String inEventTitle, String inEventVersion, int inEventCount) { super(XWikiContext.EXECUTIONCONTEXT_KEY, context.clone()); LOG.warn("(delayed) delayed observer initting. ") this.xwiki = xwiki; this.fullName = fullName; this.context = context; this.inEventTitle = inEventTitle; this.inEventVersion = inEventVersion; this.inEventCount = inEventCount; } private XWiki xwiki; private XWikiContext context; private String fullName, inEventTitle, inEventVersion; private int inEventCount; public void runInternal() { try { Thread.currentThread().setName("delayed observer " + fullName); LOG.warn("(delayed) delayed observer starting. ") Thread.sleep(1000); XWikiDocument doc = xwiki.getDocument(fullName, context); LOG.warn("(delayed) Title of changed document " + doc.getTitle()) LOG.warn("(delayed) Version of changed document " + doc.getVersion()) int count = 0; List o = doc.getObjects("CurrikiCode.SubAssetClass"); if(o!=null) count = o.size() LOG.warn("(delayed) Number of children: " + count); LOG.warn("(delayed) Is remote? " + Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState()); if(!(inEventVersion==doc.getVersion() && inEventTitle==doc.getTitle() && count == inEventCount)) { LOG.error("(delayed) WARNING: inEvent and and delayed do not match!!"); } } catch (Exception ex) { LOG.warn("Exception at the delayed bit: "+ ex, ex); } } } } // Register against the Observation Manager def observation = Utils.getComponent(ObservationManager.class) observation.removeListener("Changes-Version-Checker") def listener = new TryObservation(xwiki.getXWiki(), xcontext.getContext()) observation.addListener(listener) // {{/groovy}}
On Fri, Oct 5, 2012 at 6:20 PM, Paul Libbrecht <[email protected]> wrote:
The story evolved down here.
I have crafted an extra observer that listens to notifications and checks if the values are the same when in event and one second later in a spawned thread. They're not.
The code is copied below, it is inspired from the nice tutorial about observation.
Since about 36h, the observation listener below has reported 967 saves. From them, 145 indicate the warning at the end of this code.
Couldn't it be that you did several saves very quickly so when you received the remote event the database was changed again already ?
This warning indicates that the title, number of a objects of a particular class (where we observed the bug first), or version differ: - when pulled from the source of the event (XWikiDocument or LazyXWikiDocument) - or when pulled one second later with xwiki.getXWiki().getDocument().
However, and that's the crusty bit. Somehow, the attempt to reproduce the bug have almost all failed since that time as well. (no systematic way to reproduce the bug has been found, neither has there been a page that stayed different between the two nodes). We're on hold but this is a rather good surprise!
Paul
It was the request of previous versions which has failed.
All that seems quite curriki specific in there is a simple listener, using the old-style-notification, which analyzes the document and indexes it and maybe "related" documents (for example reindexes the user-document so as to display the count of contributions, or reindexes all of the resources of the user if the user has changed his name...). The IndexUpdater of the LucenePlugin does not seem to care for this (but then, it doesn't seem to measure differences). OK will try with 50 and see what I get. Not sure how this could be related unless it makes the LazyXWikiDocument fail to get the document from the database for some weird reason.
// {{groovy}} // This page should be Util.TryObservation // import org.xwiki.observation.* import org.xwiki.observation.event.* import com.xpn.xwiki.web.* import com.xpn.xwiki.* import org.xwiki.bridge.event.DocumentUpdatedEvent import com.xpn.xwiki.doc.XWikiDocument import org.apache.commons.logging.Log import org.apache.commons.logging.LogFactory import com.xpn.xwiki.util.AbstractXWikiRunnable import org.xwiki.observation.remote.RemoteObservationManagerContext
class TryObservation implements EventListener {
static final Log LOG = LogFactory.getLog("groovyPages.Sandbox.TryObservation"); boolean DEBUG = LOG.isDebugEnabled();
XWiki xwiki XWikiContext xcontext
TryObservation(xwiki, xcontext) { this.xwiki = xwiki this.xcontext = xcontext }
String getName() { // The unique name of this event listener return "Changes-Version-Checker" }
List<Event> getEvents() { // The list of events this listener listens to return Arrays.asList(new DocumentUpdatedEvent()) }
// Called by the Observation Manager when an event matches the list of events returned // by getEvents() void onEvent(Event event, Object source, Object data) { XWikiDocument xdoc = source; LOG.warn("Received event: " + event + ", source: " + source); LOG.warn("Title of changed document " + xdoc.getTitle()) LOG.warn("Version of changed document " + xdoc.getVersion()) int count = 0; List o = xdoc.getObjects("CurrikiCode.SubAssetClass"); if(o!=null) count = o.size() LOG.warn("Number of children: " + count);
LOG.warn("Is remote? " + Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState());
Thread obs = new Thread(new DelayedObserver(xwiki, xcontext, xdoc.getFullName(), xdoc.getTitle(), xdoc.getVersion(), count),"delayed obs"); obs.start(); LOG.warn("started obs " + obs); // Prevent infinite recursion since in this example we log to wiki page which // triggers a document change... :) /* if (source.fullName != "Sandbox.TryObservation") { def document = xwiki.getDocument("Sandbox.TryObservation") document.setContent("${document.getContent()}\n${source.fullName} has changed") document.save("Logging event", true) } */ }
public static class DelayedObserver extends AbstractXWikiRunnable {
public DelayedObserver(XWiki xwiki, XWikiContext context, String fullName, String inEventTitle, String inEventVersion, int inEventCount) { super(XWikiContext.EXECUTIONCONTEXT_KEY, context.clone()); LOG.warn("(delayed) delayed observer initting. ") this.xwiki = xwiki; this.fullName = fullName; this.context = context; this.inEventTitle = inEventTitle; this.inEventVersion = inEventVersion; this.inEventCount = inEventCount; }
private XWiki xwiki; private XWikiContext context; private String fullName, inEventTitle, inEventVersion; private int inEventCount;
public void runInternal() { try { Thread.currentThread().setName("delayed observer " + fullName); LOG.warn("(delayed) delayed observer starting. ") Thread.sleep(1000); XWikiDocument doc = xwiki.getDocument(fullName, context); LOG.warn("(delayed) Title of changed document " + doc.getTitle()) LOG.warn("(delayed) Version of changed document " + doc.getVersion()) int count = 0; List o = doc.getObjects("CurrikiCode.SubAssetClass"); if(o!=null) count = o.size() LOG.warn("(delayed) Number of children: " + count); LOG.warn("(delayed) Is remote? " + Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState()); if(!(inEventVersion==doc.getVersion() && inEventTitle==doc.getTitle() && count == inEventCount)) { LOG.error("(delayed) WARNING: inEvent and and delayed do not match!!"); } } catch (Exception ex) { LOG.warn("Exception at the delayed bit: "+ ex, ex); } } }
}
// Register against the Observation Manager
def observation = Utils.getComponent(ObservationManager.class) observation.removeListener("Changes-Version-Checker") def listener = new TryObservation(xwiki.getXWiki(), xcontext.getContext()) observation.addListener(listener)
// {{/groovy}} _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Oct 9, 2012 at 9:47 AM, Thomas Mortagne <[email protected]> wrote:
On Fri, Oct 5, 2012 at 6:20 PM, Paul Libbrecht <[email protected]> wrote:
The story evolved down here.
I have crafted an extra observer that listens to notifications and checks if the values are the same when in event and one second later in a spawned thread. They're not.
The code is copied below, it is inspired from the nice tutorial about observation.
Since about 36h, the observation listener below has reported 967 saves. >From them, 145 indicate the warning at the end of this code.
Couldn't it be that you did several saves very quickly so when you received the remote event the database was changed again already ?
I mean during the 1s you waited.
This warning indicates that the title, number of a objects of a particular class (where we observed the bug first), or version differ: - when pulled from the source of the event (XWikiDocument or LazyXWikiDocument) - or when pulled one second later with xwiki.getXWiki().getDocument().
However, and that's the crusty bit. Somehow, the attempt to reproduce the bug have almost all failed since that time as well. (no systematic way to reproduce the bug has been found, neither has there been a page that stayed different between the two nodes). We're on hold but this is a rather good surprise!
Paul
It was the request of previous versions which has failed.
All that seems quite curriki specific in there is a simple listener, using the old-style-notification, which analyzes the document and indexes it and maybe "related" documents (for example reindexes the user-document so as to display the count of contributions, or reindexes all of the resources of the user if the user has changed his name...). The IndexUpdater of the LucenePlugin does not seem to care for this (but then, it doesn't seem to measure differences). OK will try with 50 and see what I get. Not sure how this could be related unless it makes the LazyXWikiDocument fail to get the document from the database for some weird reason.
// {{groovy}} // This page should be Util.TryObservation // import org.xwiki.observation.* import org.xwiki.observation.event.* import com.xpn.xwiki.web.* import com.xpn.xwiki.* import org.xwiki.bridge.event.DocumentUpdatedEvent import com.xpn.xwiki.doc.XWikiDocument import org.apache.commons.logging.Log import org.apache.commons.logging.LogFactory import com.xpn.xwiki.util.AbstractXWikiRunnable import org.xwiki.observation.remote.RemoteObservationManagerContext
class TryObservation implements EventListener {
static final Log LOG = LogFactory.getLog("groovyPages.Sandbox.TryObservation"); boolean DEBUG = LOG.isDebugEnabled();
XWiki xwiki XWikiContext xcontext
TryObservation(xwiki, xcontext) { this.xwiki = xwiki this.xcontext = xcontext }
String getName() { // The unique name of this event listener return "Changes-Version-Checker" }
List<Event> getEvents() { // The list of events this listener listens to return Arrays.asList(new DocumentUpdatedEvent()) }
// Called by the Observation Manager when an event matches the list of events returned // by getEvents() void onEvent(Event event, Object source, Object data) { XWikiDocument xdoc = source; LOG.warn("Received event: " + event + ", source: " + source); LOG.warn("Title of changed document " + xdoc.getTitle()) LOG.warn("Version of changed document " + xdoc.getVersion()) int count = 0; List o = xdoc.getObjects("CurrikiCode.SubAssetClass"); if(o!=null) count = o.size() LOG.warn("Number of children: " + count);
LOG.warn("Is remote? " + Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState());
Thread obs = new Thread(new DelayedObserver(xwiki, xcontext, xdoc.getFullName(), xdoc.getTitle(), xdoc.getVersion(), count),"delayed obs"); obs.start(); LOG.warn("started obs " + obs); // Prevent infinite recursion since in this example we log to wiki page which // triggers a document change... :) /* if (source.fullName != "Sandbox.TryObservation") { def document = xwiki.getDocument("Sandbox.TryObservation") document.setContent("${document.getContent()}\n${source.fullName} has changed") document.save("Logging event", true) } */ }
public static class DelayedObserver extends AbstractXWikiRunnable {
public DelayedObserver(XWiki xwiki, XWikiContext context, String fullName, String inEventTitle, String inEventVersion, int inEventCount) { super(XWikiContext.EXECUTIONCONTEXT_KEY, context.clone()); LOG.warn("(delayed) delayed observer initting. ") this.xwiki = xwiki; this.fullName = fullName; this.context = context; this.inEventTitle = inEventTitle; this.inEventVersion = inEventVersion; this.inEventCount = inEventCount; }
private XWiki xwiki; private XWikiContext context; private String fullName, inEventTitle, inEventVersion; private int inEventCount;
public void runInternal() { try { Thread.currentThread().setName("delayed observer " + fullName); LOG.warn("(delayed) delayed observer starting. ") Thread.sleep(1000); XWikiDocument doc = xwiki.getDocument(fullName, context); LOG.warn("(delayed) Title of changed document " + doc.getTitle()) LOG.warn("(delayed) Version of changed document " + doc.getVersion()) int count = 0; List o = doc.getObjects("CurrikiCode.SubAssetClass"); if(o!=null) count = o.size() LOG.warn("(delayed) Number of children: " + count); LOG.warn("(delayed) Is remote? " + Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState()); if(!(inEventVersion==doc.getVersion() && inEventTitle==doc.getTitle() && count == inEventCount)) { LOG.error("(delayed) WARNING: inEvent and and delayed do not match!!"); } } catch (Exception ex) { LOG.warn("Exception at the delayed bit: "+ ex, ex); } } }
}
// Register against the Observation Manager
def observation = Utils.getComponent(ObservationManager.class) observation.removeListener("Changes-Version-Checker") def listener = new TryObservation(xwiki.getXWiki(), xcontext.getContext()) observation.addListener(listener)
// {{/groovy}} _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
participants (2)
-
Paul Libbrecht -
Thomas Mortagne