Hello,

This issue was reported against Hibernate Search 5.x or earlier, and doesn't seem to be relevant to newer Hibernate Search versions (6.x+).

In order to focus on newer versions, we are going to close this issue.

If you are still affected by this issue on Hibernate Search 6.0 or later, and have a reproducer, please comment here or reach out to us so we can reopen the issue.

If you are still affected by this issue on Hibernate Search 5.x, and want to provide a fix, please comment here or reach out to us so we can work out the next steps with you.

Cheers,
Yoann

Interesting, that might be easier than expected then, but we at least need some tests to verify this, and make sure one doesn't need to take some special care in configuration.

It might need a custom ErrorHandler, as we're not letting all exceptions bubble up to the backend caller.

@Sanne Grinovero This is and has always been the case at least in my mind. Let me clarify.

I always expected the master to be a MDB and thus be involved in transactions. So if a JMS message can not be consumed, it goes back tot he queue. This is confirmed by the fact that AbstractJMSHibernateSearchController explicitly calls indexManager.performOperations.

Now, if a user set the backend as a hibernate.search.worker.execution async then indeed the actual indexing is not transactional. Do you want us to disallow such an option if we are running on the master? That would be a good idea I think especially with our IO optimization.