Hi,

In My application indexes are present on a shared Directory on a NFS mount and is updated by two nodes and Searched by 1 node. I am getting NFS stale handle exception during searching on heavy load times.

I found in Lucene forum that if I use a different IndexDeletionPolicy and we can get around this Problem.
Any Idea how to implement this in Hibernate Search?

Thanks in advance for your help

Regards
Arnab

Hi Arnab,
you're correct, keeping the indexes on NFS can be troublesome.

In Hibernate Search it's currently not possible to customize the IndexDeletionPolicy, but patching the code to do so would not be a hard task, I can give you some pointers and if you can create the patch and include the needed changes to documentation we will include this feature in version 4.0, which is coming very soon (a week or two).

Which version of Hibernate Search are you using? Can you upgrade to 4? I'm asking because I don't think the project lead would be happy to apply such a patch to older branches; new features should come in newer releases.

In practice there is an alternative solution:
Use filesystem-master and filesystem-slave (as described here) in combination with the JMS backend, as described here
This approach might be slightly more complex to configure, but has several benefits:
* Just one node writes to the Index, so you don't have lock contention. In you scenario having two nodes writing you might have timeouts; while having a single node writing you can enable the option exclusive_index_use which improves performance a lot.
* All queries are run from locally stored indexes, and will be much faster too.

Hi Sanne,

Thanks for such prompt reply.
That's really great news, I will wait for that release. We are currently using Hibernate search 3.1.1 and we can definitely upgrade to 3.4 but has to go through the usual transition phases of testing.

So for an immediate fix I have started looking at the master slave configuration which you mentioned here and looks really promising. But I have one question:
Consider the given scenario:

NODE A -
1) Set up as a SLAVE
2) Creates/updates indexes Transactionally - The requests are queued to the Master (NODE B)
3) Runs searches on the local copy.

NODE B -
1) Set up as a MASTER
2) Serves the index creation requests for the SLAVE (NODE A)
3) updates indexes Transactionally

If NODE A queues index creation request or an update request, will that index be present in the Local copy of NODE A immediately? Will that index be available for searching at NODE A immediately or it will only appear once the NODE B(MASTER) has written the indexes and the NODE A local copy is synced?

Thanks in advance for your help.

Regards
Arnab

You should start creating a "new feature" on JIRA : https://hibernate.onjira.com/browse/HSEARCH
and I look forward for some help :) contributing patch would be ideal, otherwise even trying out our code in early snapshots would be nice.


I'd suggest moving to 4.0 if possible, or at least 3.4.1 if 4.0 is too complex to migrate to in a single step (it needs Hibernate Core 4.0 too).


NODE A will only see the changes after each copy is synced, so not immediately. If you need real-time replication then you need to configure Infinispan http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#infinispan-directories as a Directory, and still use the same master+slave backends so you have a single node writing, but it will write to the same index "instance" and affect search results on the other node too immediately.

Hi Sanne,

Here is ticket : https://hibernate.onjira.com/browse/HSEARCH-952

Regards
Arnab