jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: search index corruption?
Date Sun, 03 Oct 2004 21:48:54 GMT
hi paul,

thanks a lot for the post.

> ... or rather less elegantly by adding a 
> 'shutdown-hook' to the JVM using 
> Runtime.addShutdownHook(Thread).
> Using the 'finally' block would be the better way, and 
> would ensure that the repository is properly shutdown 
> regardless of what happens in the main loop of your test. 
> Even an OutOfMemoryError would trigger the repository being 
> shutdown -- that said, with an OOME, all bets are 
> off when it comes to running any code at all ;) The only time 
> this wouldn't shut the repository down properly is if the JVM 
> itself crashed -- does happen, but not very often, I hope! 
> Hopefully this will mean that the repository is not shutdown 
> properly so rarely that you don't /need/ (at least in the short-term) 
> to have an automatically recovering repository index.
i agree that there is no short-term need for the index to
recover and certainly the "finally" or the "jvm shutdown hook"
would both have solved my issue easily (or even as marcel
suggested just having repof.shutdown() ouside the try catch).

unfortunately, recently i am a bit burnt with vm's that crash or 
hang and unfortunately applications even more so. one application
deadlock or endless loop and a trigger-happy sysadmin stopping
your jvm with kill -9 is enough.

so i am just generally suspicious towards "infrastructure" like a 
repository that can get into an inconsistent state just because
it has been abnormally terminated.
especially if that "infrastructure" runs in the same jvm as 
the application and therefore restarting the jvm might happen 
very frequently and under unexpected circumstances.

anyhow, no immediate action necessary anyway ;)


View raw message