jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks" <marti...@gx.nl>
Subject RE: Clustering: JournalException
Date Wed, 09 May 2007 08:08:39 GMT
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: martijnh@gx.nl
 
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/  

> -----Original Message-----
> From: dominique.pfister@gmail.com 
> [mailto:dominique.pfister@gmail.com] On Behalf Of Dominique Pfister
> Sent: Friday, May 04, 2007 5:05 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: Clustering: JournalException
> 
> Hi Martijn,
> 
> On 5/4/07, Martijn Hendriks <martijnh@gx.nl> 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: martijnh@gx.nl
> >
> > Wijchenseweg 111
> > 6538 SW Nijmegen
> > http://www.gx.nl/
> >
> > > -----Original Message-----
> > > From: dominique.pfister@gmail.com
> > > [mailto:dominique.pfister@gmail.com] On Behalf Of 
> Dominique Pfister
> > > Sent: Thursday, May 03, 2007 3:32 PM
> > > To: dev@jackrabbit.apache.org
> > > Subject: Re: Clustering: JournalException
> > >
> > > Hi Martijn,
> > >
> > > On 5/3/07, Martijn Hendriks <martijnh@gx.nl> 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: martijnh@gx.nl
> > > >
> > > > Wijchenseweg 111
> > > > 6538 SW Nijmegen
> > > > http://www.gx.nl/
> > > >
> > >
> >
> 

Mime
View raw message