Hello!
We are attempting to use Hibernate Search in our project together with Infinispan. We have looked in the documentation and tried the easiest configuration, just to define infinispan as provider. When starting the application (deployed in Tomcat) on two machines on the network, the index on both machines are updated individually but there is no communication between the machines.

We found some indication that it could be a problem with multicasting so we changed to TCP in the JGroups configuration. Eventually we got the machines to recognize each other but we got a lot of locking problems. We then tried to set up Master/Slave but we want both instances in the cluster to be equal so both should be master and slave at the same time. Is this possible to set up in Hibernate Search?
We have only managed to update the index from one machine to the other, not both ways.
Our Hibernate properties looks like this.

<property name="jpaProperties">
<props>
<prop key="hibernate.ejb.naming_strategy">org.hibernate.cfg.ImprovedNamingStrategy</prop>
<prop key="hibernate.dialect">org.hibernate.dialect.Oracle10gDialect</prop>
<prop key="hibernate.format_sql">true</prop>
<prop key="hibernate.use_sql_comments">true</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.search.default.directory_provider">infinispan</prop>
<prop key="hibernate.search.lucene_version">LUCENE_35</prop>
<prop key="hibernate.search.infinispan.configuration_resourcename">
tlr-hibernatesearch-infinispan.xml
</prop>
<prop key="hibernate.search.analyzer">org.apache.lucene.analysis.standard.StandardAnalyzer</prop>
</props>
</property>
This is our infinispan propewrties

<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
xmlns="urn:infinispan:config:5.1">

<!-- *************************** -->
<!-- System-wide global settings -->
<!-- *************************** -->

<global>

<!-- Duplicate domains are allowed so that multiple deployments with default configuration
of Hibernate Search applications work - if possible it would be better to use JNDI to share
the CacheManager across applications -->
<globalJmxStatistics
enabled="true"
cacheManagerName="HibernateSearch"
allowDuplicateDomains="true" />

<!-- If the transport is omitted, there is no way to create distributed or clustered
caches. There is no added cost to defining a transport but not creating a cache that uses one,
since the transport is created and initialized lazily. -->
<transport
clusterName="HibernateSearch-Infinispan-cluster">
<properties>
<property name="configurationFile" value="jgroups-tcp.xml" />
</properties>

<!-- Note that the JGroups transport uses sensible defaults if no configuration
property is defined. See the JGroupsTransport javadocs for more flags -->
</transport>

<!-- Note that the JGroups transport uses sensible defaults if no configuration property
is defined. See the Infinispan wiki for more JGroups settings:
http://community.jboss.org/wiki/ClusteredConfigurationQuickStart -->

<!-- Used to register JVM shutdown hooks. hookBehavior: DEFAULT, REGISTER, DONT_REGISTER.
Hibernate Search takes care to stop the CacheManager so registering is not needed -->
<shutdown
hookBehavior="DONT_REGISTER" />

</global>

<!-- *************************** -->
<!-- Default "template" settings -->
<!-- *************************** -->

<default>

<locking
lockAcquisitionTimeout="20000"
writeSkewCheck="false"
concurrencyLevel="500"
useLockStriping="false" />

<!-- Invocation batching is required for use with the Lucene Directory -->
<invocationBatching
enabled="true" />

<!-- This element specifies that the cache is clustered. modes supported: distribution
(d), replication (r) or invalidation (i). Don't use invalidation to store Lucene indexes (as
with Hibernate Search DirectoryProvider). Replication is recommended for best performance of
Lucene indexes, but make sure you have enough memory to store the index in your heap.
Also distribution scales much better than replication on high number of nodes in the cluster. -->
<clustering
mode="replication">

<!-- Prefer loading all data at startup than later -->
<stateTransfer
timeout="480000"
fetchInMemoryState="true" />

<!-- Network calls are synchronous by default -->
<sync
replTimeout="20000" />
</clustering>

<jmxStatistics
enabled="true" />

<eviction
maxEntries="-1"
strategy="NONE" />

<expiration
maxIdle="-1" />

</default>

<!-- ******************************************************************************* -->
<!-- Individually configured "named" caches. -->
<!-- -->
<!-- While default configuration happens to be fine with similar settings across the -->
<!-- three caches, they should generally be different in a production environment. -->
<!-- -->
<!-- Current settings could easily lead to OutOfMemory exception as a CacheStore -->
<!-- should be enabled, and maybe distribution is desired. -->
<!-- ******************************************************************************* -->

<!-- *************************************** -->
<!-- Cache to store Lucene's file metadata -->
<!-- *************************************** -->
<namedCache
name="LuceneIndexesMetadata">
<clustering
mode="replication">
<stateTransfer
fetchInMemoryState="true" />
<sync
replTimeout="25000" />
</clustering>
</namedCache>

<!-- **************************** -->
<!-- Cache to store Lucene data -->
<!-- **************************** -->
<namedCache
name="LuceneIndexesData">
<clustering
mode="replication">
<stateTransfer
fetchInMemoryState="true" />
<sync
replTimeout="25000" />
</clustering>
</namedCache>

<!-- ***************************** -->
<!-- Cache to store Lucene locks -->
<!-- ***************************** -->
<namedCache
name="LuceneIndexesLocking">
<clustering
mode="replication">
<stateTransfer
fetchInMemoryState="true" />
<sync
replTimeout="25000" />
</clustering>
</namedCache>

</infinispan>

And our Jgroups propeties
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups file:schema/JGroups-3.0.xsd">
<TCP
bind_addr="GLOBAL"
bind_port="7800"
loopback="true"
port_range="30"
recv_buf_size="20m"
send_buf_size="640k"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
enable_bundling="true"
use_send_queues="true"
enable_diagnostics="false"
bundler_type="old"

thread_naming_pattern="pl"

thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="30"
thread_pool.keep_alive_time="60000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="100"
thread_pool.rejection_policy="Discard"

oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="2"
oob_thread_pool.max_threads="30"
oob_thread_pool.keep_alive_time="60000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Discard"
/>


<TCPPING timeout="3000"
initial_hosts="localhost[7800],172.16.200.75[7800]"
port_range="1"
num_initial_members="2"
ergonomics="false"
/>

<VERIFY_SUSPECT timeout="1500" />
<pbcast.NAKACK
use_mcast_xmit="false"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
view_bundling="true"/>

</config>

Regards
Andreas

Hi Andreas,
if you want to configure both nodes equally you should at least set

or each node will assume it is the only writer (and attempt to acquire an exclusivity lock which is likely the error you are having).

This configuration might be perfect for failover & simplicity, however this doesn't scale too well if you have a large amount of writes to handle: to be able to scale better on writes you should pick a node to be configured as Master: this node will require a different set of properties.

Could you explain why it is important for you to have both nodes configured exactly the same? You could for example use system/environment properties: in that case the configuration files would be the same, but you would still need to set different environment properties.

Hello!
Thank you for the answer.
Yes, we ended up using hibernate.search.​default.​exclusive_index_use=false and no Master/Slave. Our application doesn't have intensive update operations to the index, mostly reading. The reason we don't want Master/Slave configuration is failover and ease to add and remove nodes to the cluster. As I understand it, all the writing to the index must be performed by the Master node and we don't want those restrictions either, all nodes should be able to update.
Regards
Andreas

So your problem is solved or are you still having locking issues?

Our problems are solved, hibernate.search.​default.​exclusive_index_use=false fixed the locking issues when creating the index. Sadly, we might not be allowed to implement our freetext search in HS, we probably have to use the Oracle Text functions instead.

HS was created because that was a huge pain to use :-)

Would you mind sharing the reasons, if they are technical? If I can, I'd like to improve Hibernate Search to avoid such needs.

No technical reasons, only political :-)

:-(
Let me know if we can help. name at hibernate.org