Hi Martijn, Looks like you could reproduce this bug, that's great! Yes, please create a JIRA issue, i will take a look at it as soon as possible.
Kind regards Dominique On 5/9/07, Martijn Hendriks <[EMAIL PROTECTED]> wrote:
Hi Dominique, There seems to be a race condition that may cause duplicate search index entries. I do the following (Jackrabbit 1.3): 1) Start clusternode 1 that just adds one node "A" of nodetype clustering:test. 2) Shutdown clusternode 1. 3) Start clusternode 2 that performs the search //element(*, clustering:test). 4) Print the result of the search (UUIDs of nodes in the result set). When I just run clusternode 2, then there is one node in the resultset, as expected. However, when I debug clusternode 2 (starting with an empty search index) and have a breakpoint (i.e., a pause of a few seconds at line 306 of RepositoryImpl.java - just before the clusternode is started), then the resultset contains two results, both with the same UUID. Should I create a JIRA issue for this? Best wishes, Martijn Hendriks <GX> creative online development B.V. t: 024 - 3888 261 f: 024 - 3888 621 e: [EMAIL PROTECTED] Wijchenseweg 111 6538 SW Nijmegen http://www.gx.nl/ > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dominique Pfister > Sent: Friday, May 04, 2007 5:05 PM > To: [email protected] > Subject: Re: Clustering: JournalException > > Hi Martijn, > > On 5/4/07, Martijn Hendriks <[EMAIL PROTECTED]> wrote: > > Now we have the following problem: We have a setup with two > > clusternodes. The idea is that first one of these clusternodes > > initializes the repository (initial content, nodetypes and > namespaces). > > When this is done, the second clusternode can start (with only a > > repository.xml and no search index). The second clusternode fails > > unfortunatly. It seems that its search index contains duplicate > > entries (which causes its failure). Taking a look at the > > RepositoryImpl code I think that I've found the cause. The > constructor > > first starts the search managers which build the local > search index from the shared database. > > Then the clusternode is started which synchronizes the changes from > > its local revision 0 up to the global revision. This > synchronization, > > however, triggers events that are picked-up and processed by the > > search manager. This causes duplicate entries, or doesn't it? > > It shouldn't, actually. I would expect the events to > regenerate entries in the search index that were already > up-to-date, in the worst case. Can you explain in more detail > what errors are occurring? Some short test, containing > repository initialization code that reliably causes errors on > the second cluster node would be helpful, too. > > Kind regards > Dominique > > > > > Best wishes, > > > > Martijn Hendriks > > <GX> creative online development B.V. > > > > t: 024 - 3888 261 > > f: 024 - 3888 621 > > e: [EMAIL PROTECTED] > > > > Wijchenseweg 111 > > 6538 SW Nijmegen > > http://www.gx.nl/ > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > Dominique Pfister > > > Sent: Thursday, May 03, 2007 3:32 PM > > > To: [email protected] > > > Subject: Re: Clustering: JournalException > > > > > > Hi Martijn, > > > > > > On 5/3/07, Martijn Hendriks <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > During the testing of a clustered Jackrabbit 1.3 setup we > > > came across > > > > the issue that spaces in the names of nodetype definitions > > > (which is > > > > allowed by the JSR 170 spec if I remember correctly) cause > > > > JournalExceptions: > > > > > > > > This is caused by something like this in the revision data: > > > > > > > > - wo:form_new routing (string) > > > > > > > > I guess that this is a bug, or are spaces in propertynames > > > forbidden? > > > > > > You're right, it is a bug, namely: > > > > > > http://issues.apache.org/jira/browse/JCR-895 > > > > > > Internally, nodetype registrations were saved as embedded CNDs in > > > the journal and QName(s) were not escaped. Since a space > is treated > > > as a whitespace delimeter, this caused the parsing error you > > > described when reading back a QName with spaces in it. > > > > > > I fixed this bug in the main trunk. Thank you very much for > > > reporting it! > > > > > > Kind regards > > > Dominique > > > > > > > > > > > Best regards, > > > > > > > > Martijn Hendriks > > > > <GX> creative online development B.V. > > > > > > > > t: 024 - 3888 261 > > > > f: 024 - 3888 621 > > > > e: [EMAIL PROTECTED] > > > > > > > > Wijchenseweg 111 > > > > 6538 SW Nijmegen > > > > http://www.gx.nl/ > > > > > > > > > >
