jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Neale" <michael.ne...@gmail.com>
Subject Re: Index/data corruption
Date Fri, 27 Apr 2007 00:15:11 GMT
yeah it looks like it is a problem that happens when it is not shutdown
properly (which mostly happens in my unit tests) - so once I make sure it
shuts down, its ok.

but there is a problem with the recovery code not working - but that can be
corrected by blowing away the indexes.

On 4/26/07, Willis Morse <willismorse@mac.com> wrote:
>
> Great, thanks for the info Marcel.
>
> - Will
>
>
> On Apr 25, 2007, at 4:19 PM, Marcel Reutegger wrote:
>
> > Willis Morse wrote:
> >> Is the indexing done asynchronously?
> >
> > no, but it is also not completely synchronously ;)
> >
> > the query handler writes a forward log with the index changes. then
> > the changes are indexed but not immediately written to disk. this
> > is done synchronously. you can configure an idle time for the in
> > memory part of the index to be written to disk.
> >
> > some part of the indexing may be asynchronous, but not by default:
> > text extraction from nt:resource nodes. if you configure the
> > extractorPoolSize parameter in the SearchIndex element.
> >
> > See: http://issues.apache.org/jira/browse/JCR-390
> >
> >> In my Swing app, I might do something like this:
> >>     session.save();
> >>     session.logout();
> >>     System.exit();
> >> Is this safe?
> >
> > this depends on how you instantiated the repository. if you are
> > using a TransientRepository it should be safe because once the
> > session (assuming it is the only session your application uses)
> > logs out the underlying repository is also shutdown.
> >
> > if you started jackrabbit manually you should also shut it down
> > before you exit the jvm. I say should because jackrabbit is able to
> > handle this case and also the derby database. even though this is
> > not the preferred way, because it forces  derby but also the query
> > handler to potentially process a forward log when jackrabbit is
> > started the next time. so, whenever possible you should shut down
> > jackrabbit properly before you exit the jvm (under the assumption
> > that you are using jackrabbit in-process and not via rmi).
> >
> >> If not, how do we programmatically determine when it is safe to
> >> exit the app?
> >
> > Call RepositoryImpl.shutdown() when you are finished using
> > jackrabbit and then exit.
> >
> > regards
> >  marcel
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message