hibernate-search-backend-jgroups is incompatible with infinispan Version 9.xxx because of this.
Hi , yes I'm aware of that. Do you use them together? I would be eager to know more about your use case.
In my experience the people combining hibernate-search-backend-jgroups with the Infinispan Directory are running on WildFly. Latest WildFly still is using JGroups 3 as well so that's why I've put this on hold.
Incidentally people running on WildFly wouldn't have problems to use Infinispan 9 as the modules are isolated, so it can use both. So I take it you're not on WildFly?
I'm currently working on a prototyp, where I have to add "Google" like Searching to our existing application. To keep the deployment simple, Elasticsearch is not a preferable option. But still there is a requirement for a multinode deployment. We use Tomcat Servers.
So my setup is like that: HibernateSearch with Infinispan backend. Each node should have his local index, to keep the index alive, the plan is to save the index to a persistence database. This because there is also the requirement, to restart a single node server without loosing the index.
As the configuration for Infinispan is different on 8.xx and 9.xxx (Infinispan Persistence Example, I tried to use the newest version.
But excluding the depencendy in Maven for both ends didn't help.
Thanks for the details. I agree that what you're trying to do makes sense, unfortunately the current version is not compatible with JGroups 4 yet; I was planning to do this but I won't be able to work on this for some more weeks.
These are the options you have, I think:
Use latest Infinispan 8.2.x with JGroups 3 and the current hibernate-search-backend-jgroups
Use Infinispan 9 with our JMS backend instead
Use WildFly instead of Tomcat, so that it's not a problem to mix our JGroups 3 based backend with Infinispan 9 using JGroups 4.
Contribute to the project by fixing this issue
We're going to need to finish this upgrade for version 5.9, or alternatively rather than binding to JGroups directly we could use the WildFly clustering API.
In that second option we'd benefit from some nice features from the clustering subsystems, like clustered singleton deployments and decoupling from the specific JGroup version used in the server. The drawback would be that people not interested in WildFly would not be able to use this specific backend.