Hibernate-search 6 Error handler implementation

#1

Hello,
How do you use an error handler with Hibernate search 6.
I don’t find for the moment in the alpha-8 documentation or in the sample code (the ErrorHandler is moved to the legacy section)

I tried to add the property
“hibernate.search.backends.[myBackend].error_handler”
and
“hibernate.search.error_handler”

I set my property to a full qualified class name “my.package.IndexUpdateErrorHandler”
The class is declared as “public class IndexUpdateErrorHandler implements ErrorHandler”
but I never reach the code in “handle” neither “handleException”.
I tried with some basic errors such as

  • my database not reachable
  • my elasticsearch not reachable
  • a field not acceptable in elasticsearch (example a @GenericField > 32kb)

I see on all cases a lot of exception log but I cannot manage my errors with the handler.

1 Like
#2

Error handlers are not really implemented in Search 6 yet.
You can follow progress here: https://hibernate.atlassian.net/browse/HSEARCH-3110

Could you explain in details what events you need to intercept and what you need to do with them? That will help us a lot to shape out the feature.

#3

Thank you for your fast answer.
We’d like to use a batch program to reindex all data using the mass indexer.
We’d like to manage errors during indexing process to monitor and adapt our process (maybe retry several times and alert).
We’d like to have an error status at the end of the mass indexer.

We don’t know exactly the error we are looking for, but on the 3 identified cases below, the only hint we have error is reading the log

  • my database not reachable
  • my elasticsearch not reachable
  • a field not acceptable in elasticsearch (example a @GenericField > 32kb)
#4

If I understand correctly, your main problem is that the mass indexer does not terminate with a useful exception when something goes wrong?

If we were to change the mass indexer so that the call to startAndWait() throws the original exception (or another exception with the proper cause), plus some context to identify the entity that caused the problem, would that work for you? Or would you still need an error handler?

1 Like
#5

Yes, it would be more adapted to our use case.

#6

Is it planned in a next alpha / beta - release ?

#7

It will happen in beta release, but I can’t give you a time frame for now. You can follow HSEARCH-3110 for updates. If you want to contribute and have the time for that, we can discuss it on that ticket.

By the way , when you said “it would be more adapted to our use case”, did you mean:

  1. Changing the mass indexer so that the call to startAndWait() throws the original exception (or another exception with the proper cause), plus some context to identify the entity that caused the problem
  2. Or just the old-fashioned error handler?
#8

In fact, both solution is adapted to our use case.

Actually, I don’t have the time to contribute efficiently to the project, I tried to debug and implement an exception solution but I didn’t manage to understand how to manage the multithreaded indexor with a correct error management

#9

Ok, no problem. We’ll get there eventually :slight_smile: