I tried many combinations but it didn't work so I decided to change the architecture :)

I'm using a central node to which the clients connect using remote EJB calls. The central node then sends out the messages using JMS to all the clients, including the one who sent the message in the first place, since I understand the index is not updated there automatically if I'm using a custom backend worker?

The problem I'm having now is related to the issue you reported here : https://hibernate.atlassian.net/browse/HSEARCH-1868

The connections from the client nodes to the central node work. The data is sent correctly and the JMS messages are sent back to the clients. Now, the problem is with:



SearchIntegrator and SearchFactory are, obviously, not the same :) so I don't know how to handle the incoming messages, i.e. how to update the index on the client node using the SearchFactory object returned by the FullTextEntityManager. Is there any other way to get to an IndexManager instance for a given IndexName?

interesting architecture :)

These examples should have what you need?

How to get a SearchIntegrator from the EntityManager:
https://github.com/hibernate/hibernate-search/blob/a5c71698f86d9c80106d6ad19d6e9808a1d1d8af/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/jms/controller/RegistrationMdb.java#L32

How to apply the indexing work given the SearchIntegrator:
https://github.com/hibernate/hibernate-search/blob/9db0676b794707865be0022a164d3c391c8629d5/backends/jms/src/main/java/org/hibernate/search/backend/impl/jms/AbstractJMSHibernateSearchController.java#L64

Thanks...? :)



Yup, the solution I found on SO is the same. I'm also using the AbstractJMSHibernateSearchController as a template to apply the indexing work. However, not everything is perfect. See below :)

I found the following solution : http://stackoverflow.com/questions/28206502/access-directory-in-hibernate-search-5/28232872#28232872



And it's working!

It's not the end of my problems, though :)

It seems like the applyWork method in my BackendQueueProcessor class is being called constantly, even though there are no changes introduced in the database / the index... Is there some kind of acknowledgment mechanism that I need to use to let it know that the messages have been sent and received?

Or is it possible that I'm creating an endless loop? Does the execution of trigger another round of messages?

EDIT:

I'm pretty sure that's the case. I'm never really storing anything in the index because calling just calls my own BackendQueueProcessor, which sends the packet to the central node, which sends it to the clients, and so on... In the client node receiver I would like to call the default lucene worker to store the changes in the local index. Is that possible?

Yes that's possible, you can fix that with configuration.
The IndexManager will in turn forward change requests to its configured backend.. make sure the node receiving these uses the "lucene" backend (org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor)

You can plug in a custom backend (implement org.hibernate.search.backend.spi.BackendQueueProcessor) and/or a custom IndexManager (org.hibernate.search.indexes.spi.IndexManager).
Both can be enabled by simply setting the fully qualified name of your implementation in the configuration settings.

The existing ones should be extendable, so that you can add some custom logic to prevent these loops, hopefully without having to copy too much code.

What you're doing is rather unusual.. let me know if by doing this setup it would help you to make some changes to our components, we can discuss that, or feel free to send a pull request as proposal.

I just edited my previous message and now you've confirmed my suspicions :)

I am using a custom BackendQueueProcessor on both of my client nodes, which both have local index directories. Due to this fact, I never really store the values to the index but keep sending JMS messages by calling my central node's remote EJB method. I need to extend or otherwise make use of the default "lucene" backend to apply the index changes in the end.



At this point, I think what I'm trying to do fits well with what is available. I simply lack some knowledge here and there which causes those problems to arise. I think when I get all this to work, this could be a nice example for multi-client multi-master setup using remote EJB.

I ended up extending both the DirectoryBasedIndexManager and the LuceneBackendQueueProcessor.

I use the former class to decide if the operation on the index should be carried out by my implementation of the BackendQueueProcessor or by the default one. I'm using the 'filesystem' directory provider so if the default operation is chosen, the setup behaves as a simple filesystem-based index.

The index update flow looks as follows.

1. An index update is triggered on Client Node A by a database operation
2. Client Node A updates its own index (filesystem-based)
3. Client Node A calls the remote EJB method on Central Node with the serialized LuceneWork queue as the parameter. It also includes it's ID (e.g. NodeA)
4. The Central Node keeps pooled JMS connection factories to all the client nodes
5. The Central Node receives the remote EJB method call and iterates over the connections sending index updates to other client nodes
6. The source node is skipped (based on the node ID) because it already updated its own index

I keep the node ID as a property in persistence.xml.

The central node has no dependencies on Hibernate Search or Lucene - it simply transfers binary data from one sender to many listeners.

We recently switched over to Wildfly 10, which came with newer versions of Hibernate Search libraries. Unfortunately, my structure is no longer working. All the processes work as expected, the messages are flowing between the central node and the client nodes but the index is not updated on the nodes which did not initiate the transfer.

I can see that some files of the index are changing but making a database request returns old, invalid data. I'm not sure what those files are and if something changed between the versions.

When Client Node A changes something in the database the following files are changed for that particular object:

-rw-r--r-- 1 wildfly wildfly 379 Jul 29 20:22 _2u9h.si
-rw-r--r-- 1 wildfly wildfly 6687 Jul 29 20:22 _2u9h.cfs
-rw-r--r-- 1 wildfly wildfly 363 Jul 29 20:22 _2u9h.cfe
-rw-r--r-- 1 wildfly wildfly 207 Jul 29 20:22 segments_2tq8

The same files are changed on Client Node B

-rw-r--r-- 1 wildfly wildfly 207 Jul 29 20:22 segments_2tq0
-rw-r--r-- 1 wildfly wildfly 379 Jul 29 20:22 _2u8v.si
-rw-r--r-- 1 wildfly wildfly 6687 Jul 29 20:22 _2u8v.cfs
-rw-r--r-- 1 wildfly wildfly 363 Jul 29 20:22 _2u8v.cfe

Even the file sizes are the same. Still, the changed value is not reflected in Client Node B.

Is there something I missed in the documentation that could explain this behavior?

EDIT: The value is updated after a minute or so but that is way too long to satisfy our needs. Could this be somehow connected with cache?

I completely disabled second level cache in the persistence.xml files and the index is updated instantly now. This most likely proves that the JMS messaing I implemented still works but our setup is not compatible with some Hibernate settings as far as cache is concerned. I think this no longer is the place to discuss this further :)