Using Infinispan as index directory provider

[mattw]

Hi,

We're using Infinispan to provide a number cache instance on a set of nodes and up until now, we've been using the "ram" directory provider for the lucene indexes.

We're looking to move this to an "infinispan" directory provider and have tried using the following in our cache configuration:

<indexing enabled="true">
     <properties>
          <property name="hibernate.search.default.directory_provider" value="infinispan" />
          <property name="hibernate.search.infinispan.configuration_resourcename" value="indexing-config.xml" />
          <property name="hibernate.search.default.locking_cachename" value="LuceneIndexesLocking" />
          <property name="hibernate.search.default.data_cachename" value="LuceneIndexesData" />
          <property name="hibernate.search.default.metadata_cachename" value="LuceneIndexesMetadata" />
     </properties>
</indexing>

The "indexing-config.xml" is a copy of the "default-hibernatesearch-infinispan.xml" provided in the "hibernate-search-infinispan" jar with just the transport changed to use TCP (as we're not allowed to use UDP.)

For a single cache, this works fine. A second CacheManager is started and manages just the lucene caches as expected.

When I add this to a second cache, another CacheManager is started to manage a new set of lucene caches.... I guess it is seeing the "configuration_resourcename" again and starting another instance. But that seems a lot of overhead when it manages the same index caches that could be shared.

So what is the best way to handle multiple cache indexes? Is there any way to do it just though the configuration?

I see you can use a JNDI reference to a CacheManager. Is it best to create the second CacheManager (I assume we can't share the original) in code and expose it to the configuration through JNDI? Or can we get the first instance to create it, and subsequent share that instance?

Any help or suggestions much appreciated.

Matt

Infinispan 5.1.5.Final

Hibernate Search 4.1.1.Final

[galder.zamarreno]

This is a limitation of the current structure, though we're working on a better solution which will enable you to inject a cache manager.

For the moment though, JNDI is probably the best solution to avoid multiple cache managers.

[mattw]

Thanks for the response.

After a it of fiddling, I've got JNDI working so now moved on to coping with lucene index locks. Will look out for any future improvements in this area...

Many thanks,

Matt