Wildfly domain mode compatible?

I have managed to install hibernate search as a module on wildfly 23. Wildfly is configured as a cluster in domain mode.

In the roadmap section indicates the following:
“Hibernate Search 6.0 only allows single-node applications, or multi-node applications where each node works independently, simply sending events to an Elasticsearch cluster.”

Does this mean that we cannot use hibernate search yet?



You can use it, and unless you have specific requirements it will work.

The two problems that are not currently addressed are mentioned just below the quote you gave:

When each node sends updates to Elasticsearch independently, conflicts may arise when entities are updated simultaneously on different nodes. There is a need to prevent, or at least resolve, these conflicts.

The main problem is the lack of coordination between nodes, so if two database transactions are executed on two separate nodes, and trigger reindexing of the same entity at the same time, with slightly different changes, it’s possible that one of the changesets will win and the other will get ignored.

That being said, this can happen on a single node as well, with two transactions executing in separate threads.

You can find a more detailed explanation here.

It just becomes more likely in a clustered application: if you’re clustering your application, you probably have more traffic and thus it may be more likely that changes in concurrent transactions affect the same indexed document.

That being said:

  • Hibernate Search 5 had this problem as well, so if you’re upgrading, there’s nothing new.
  • Depending on your mapping and on your write patterns, you may not be affected at all.
  • If you are affected, you can probably work around the problem by configuring periodic mass indexing (e.g. every night, every week, …) to correct the situation.

We’re working on a solution in Hibernate Search 6.1.

And the second issue:

For some use cases where maintenance downtime is not acceptable, Hibernate Search needs to provide hot updates at the cluster level: allow to boot application nodes with the new mapping, while some application nodes with the old mapping are still running.

That’s simply to say that if you change your mapping, you will have to stop the whole cluster, or at least put it in read-only mode while you’re restarting nodes (and accept potential failures due to incompatible mapping). That’s fine in many cases, since you probably have to do that when you update your database schema anyway. But in some cases, it may be a problem.

thank you very much for your reply