jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: handling indexing failure
Date Thu, 12 Jan 2006 10:34:13 GMT
Brian Moseley wrote:
> let me give you a second example. that ThreadDeath we're talking about
> in another list thread - that occurred in my custom text filter as
> well. it didn't cause the server to crash or even for the webdav
> request to fail. in fact, the PUT succeeded, but there was no
> indication to the user that the text filter had failed and that the
> event he just uploaded was not in fact indexed and would not be
> included in subsequent queries. so even though we had the ThreadDeath
> stack trace in the error log, we spent most of a day putting two and
> two together to figure out what was going on. it would have been more
> correct and informative for the filter to have vetoed the request or
> otherwise informed the jcr client layer that something went really
> wrong down below, so that i could have returned an error for the PUT,
> and it would have saved me time diagnosing the issue. does that make
> sense?

yes it does, and I think JCR-299 you created is a good way to address 
this issue.

> so you're saying that even when you implement vetoable listeners, text
> filters won't be vetoable? you'll continue to just log and swallow
> potentially very important exceptions that might arise within filters
> due to circumstances you can't foresee?

filters are allowed to throw a RepositoryException, those are only 
logged and will not harm index integrity. and yes, I think this should 
stay as it is.
unchecked exceptions or even errors are a different story and need to be 
handled. this is currently not the case.

if errors were handled properly with a transaction rollback, text filter 
developers will be able to abuse this and throw an unchecked exception, 
which would then trigger a rollback of the transaction. so, in the end 
you will still get vetoable text filters ;)

but that needs more thinking how this is handled deep inside jackrabbit.


View raw message