-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 11 posts ] 
Author Message
 Post subject: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Wed Jul 16, 2014 6:50 am 
Newbie

Joined: Mon Jan 27, 2014 12:40 pm
Posts: 2
Hi all,
we're facing an issue in a clustered deployment using Hibernate Search with an Infinispan directory provider and JMS master/slave topology.

We are using the following versions:
Hibernate 4.3.1.Final
Hibernate Search 4.5.1.Final
Infinispan 6.0.2 (transitive dependency of hibernate-search-infinispan)

Our current deployment is the following: 2 slave nodes, sending JMS messages for index updates and one master node responsible of consuming messages from the target JMS queue (The suggested Master/Slave topology by Hibernate with Infinispan as back-end).

After performing initialisation of the indexes, the system operates normally. However, at some undefined time, there are entries in the master node's logs, indicating message timeouts when trying to send messages via Jgroups to the slave nodes. Sometimes, after a number of these errors is logged, exceptions begin to appear indicating failure to obtain locks on some entity.

Infinispan directory provider has been configured to support persistence of the Lucene data & metadata caches, using the SingleFileStore class, in Replication mode.

We are using the default-hibernatesearch-jgroups-udp.xml for JGroups transport configuration, and our infinispan.xml configuration is the following:

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

   <!-- *************************** -->
   <!-- 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="false"
         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="test-HibernateSearch-Infinispan-cluster">

         <!-- Note that the JGroups transport uses sensible defaults if no configuration
            property is defined. See the JGroupsTransport javadocs for more flags -->
         <properties>
            <property name="configurationFile" value="default-hibernatesearch-jgroups-udp.xml" />
         </properties>
      </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" />

      <invocationBatching enabled="false" />

      <!-- 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">
        <persistence passivation="false">
            <store class="org.infinispan.persistence.file.SingleFileStore" fetchPersistentState="false" preload="true"
                   shared="false" purgeOnStartup="true" ignoreModifications="false">
                <async enabled="true" flushLockTimeout="1" shutdownTimeout="25000" modificationQueueSize="1024" threadPoolSize="1"/>
                <properties>
                    <property name="location" value="${infinispan.filestore.directory}"/>
                </properties>
            </store>
        </persistence>
        <clustering mode="replication">
            <stateTransfer fetchInMemoryState="true" />
            <sync replTimeout="60000" />
        </clustering>
    </namedCache>

   <!-- **************************** -->
   <!-- Cache to store Lucene data -->
   <!-- **************************** -->
   <namedCache name="LuceneIndexesData">
        <persistence passivation="false">
            <store class="org.infinispan.persistence.file.SingleFileStore" fetchPersistentState="false" preload="true"
                   shared="false" purgeOnStartup="true" ignoreModifications="false">
                <async enabled="true" flushLockTimeout="1" shutdownTimeout="25000" modificationQueueSize="1024" threadPoolSize="1"/>
                <properties>
                    <property name="location" value="${infinispan.filestore.directory}"/>
                </properties>
            </store>
        </persistence>
        <clustering mode="replication">
            <stateTransfer fetchInMemoryState="true" />
            <sync replTimeout="60000" />
        </clustering>
    </namedCache>

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


</infinispan>


The following Hibernate Search configuration properties are set, common between master & slave:
Code:
hibernate.search.default.directory_provider=infinispan
hibernate.search.infinispan.configuration_resourcename=infinispan.xml
hibernate.search.default.data_cachename=LuceneIndexesData
hibernate.search.default.metadata_cachename=LuceneIndexesMetadata
hibernate.search.default.locking_cachename=LuceneIndexesLocking
hibernate.search.default.exclusive_index_use=true
hibernate.search.autoregister_listeners=true


Master-specific configuration properties are the following:
Code:
hibernate.search.default.optimizer.operation_limit.max=500
hibernate.search.default.worker.thread_pool.size=25


Slave-specific configuration properties are the following:
Code:
hibernate.search.default.worker.backend=jms
hibernate.search.default.worker.jms.connection_factory=java:comp/env/jms/ConnectionFactory
hibernate.search.default.worker.jms.queue=java:comp/env/queue/hibernate.search
hibernate.search.worker.jndi.java.naming.provider.url=tcp://localhost:61616


Can you please assist?

Best Regards


Last edited by eduser on Thu Jul 17, 2014 9:42 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Thu Jul 17, 2014 8:42 am 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Hi,
could you post the JGroups configuration files too, and the full errors in the logs?
If they are large, please feel free to open a issue on JIRA and attach files to the issue.

Also, could you please verify if the errors would happen if you where to disable all CacheStore(s) ?

https://hibernate.atlassian.net/browse/HSEARCH

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Thu Jul 17, 2014 8:55 am 
Newbie

Joined: Mon Jan 27, 2014 12:40 pm
Posts: 2
Hi Sanne,
this is our JGroups configuration file:

Code:
<config xmlns="urn:org:jgroups"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.4.xsd">
   <UDP
         mcast_addr="${jgroups.udp.mcast_addr:228.6.7.8}"
         mcast_port="${jgroups.udp.mcast_port:46655}"
         tos="8"
         ucast_recv_buf_size="20m"
         ucast_send_buf_size="640k"
         mcast_recv_buf_size="25m"
         mcast_send_buf_size="640k"
         loopback="true"
         max_bundle_size="64k"
         ip_ttl="${jgroups.udp.ip_ttl:2}"
         enable_diagnostics="false"
         bundler_type="new"

         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"
         />

   <PING timeout="3000" num_initial_members="3"/>
   <MERGE2 max_interval="30000" min_interval="10000"/>

   <FD_SOCK/>
   <FD_ALL timeout="15000"/>
   <VERIFY_SUSPECT timeout="5000"/>

   <pbcast.NAKACK2
                    xmit_interval="1000"
                    xmit_table_num_rows="100"
                    xmit_table_msgs_per_row="10000"
                    xmit_table_max_compaction_time="10000"
                    max_msg_batch_size="100"/>

   <!-- UNICAST3 is the better strategy moving forward but not
        yet compatible with the JGroups version included in EAP6 -->
   <!-- <UNICAST3
              xmit_interval="500"
              xmit_table_num_rows="20"
              xmit_table_msgs_per_row="10000"
              xmit_table_max_compaction_time="10000"
              max_msg_batch_size="100"
              conn_expiry_timeout="0"/> -->

   <UNICAST2
              stable_interval="5000"
              xmit_interval="500"
              max_bytes="1m"
              xmit_table_num_rows="20"
              xmit_table_msgs_per_row="10000"
              xmit_table_max_compaction_time="10000"
              max_msg_batch_size="100"
              conn_expiry_timeout="0"/>

   <pbcast.STABLE stability_delay="500" desired_avg_gossip="5000" max_bytes="1m"/>
   <pbcast.GMS print_local_addr="false" join_timeout="3000" view_bundling="true"/>
   <tom.TOA/> <!-- the TOA is only needed for total order transactions-->

   <UFC max_credits="500k" min_threshold="0.20"/>
   <MFC max_credits="500k" min_threshold="0.20"/>
   <FRAG2 frag_size="8000"  />
   <RSVP timeout="60000" resend_interval="500" ack_on_delivery="false" />
</config>


The timeout errors that appear are the following:

Code:
ERROR|2014-07-16 12:58:30,359|Hibernate Search: Index updates queue processor for index Cd-1|        LuceneBackendQueueTask - HSEARCH000073: Error in backend
org.infinispan.util.concurrent.TimeoutException: Replication timeout for test-16472
   at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:77)
   at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:547)
   at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
   at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:220)
   at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.DistCacheWriterInterceptor.visitPutKeyValueCommand(DistCacheWriterInterceptor.java:69)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:96)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321)
   at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402)
   at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:164)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:70)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:219)
   at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:141)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
   at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.interceptors.IsMarshallableInterceptor.visitPutKeyValueCommand(IsMarshallableInterceptor.java:88)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
   at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
   at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
   at org.infinispan.CacheImpl.putInternal(CacheImpl.java:878)
   at org.infinispan.CacheImpl.put(CacheImpl.java:870)
   at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
   at org.infinispan.lucene.impl.InfinispanIndexOutput.storeBufferAsChunk(InfinispanIndexOutput.java:163)
   at org.infinispan.lucene.impl.InfinispanIndexOutput.storeCurrentBuffer(InfinispanIndexOutput.java:152)
   at org.infinispan.lucene.impl.InfinispanIndexOutput.close(InfinispanIndexOutput.java:176)
   at org.apache.lucene.index.CompoundFileWriter.close(CompoundFileWriter.java:218)
   at org.apache.lucene.index.DocumentsWriter.flush(DocumentsWriter.java:604)
   at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3587)
   at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3376)
   at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
   at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
   at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
   at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:158)
   at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:171)
   at org.hibernate.search.backend.impl.lucene.ExclusiveIndexWorkspaceImpl.afterTransactionApplied(ExclusiveIndexWorkspaceImpl.java:45)
   at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:124)
   at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
   at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:744)
ERROR|2014-07-16 12:58:30,360|Hibernate Search: Index updates queue processor for index Cd-1|               LogErrorHandler - HSEARCH000058: Exception occurred org.infinispan.util.concurrent.TimeoutException: Replication timeout for test-16472
Primary Failure:
   Entity Cd Id 23421  Work Type  org.hibernate.search.backend.UpdateLuceneWork

org.infinispan.util.concurrent.TimeoutException: Replication timeout for test-16472
   at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:77)
   at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:547)
   at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
   at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:220)
   at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.DistCacheWriterInterceptor.visitPutKeyValueCommand(DistCacheWriterInterceptor.java:69)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:96)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321)
   at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402)
   at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:164)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:70)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:219)
   at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:141)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
   at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.interceptors.IsMarshallableInterceptor.visitPutKeyValueCommand(IsMarshallableInterceptor.java:88)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
   at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
   at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
   at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
   at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
   at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
   at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
   at org.infinispan.CacheImpl.putInternal(CacheImpl.java:878)
   at org.infinispan.CacheImpl.put(CacheImpl.java:870)
   at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
   at org.infinispan.lucene.impl.InfinispanIndexOutput.storeBufferAsChunk(InfinispanIndexOutput.java:163)
   at org.infinispan.lucene.impl.InfinispanIndexOutput.storeCurrentBuffer(InfinispanIndexOutput.java:152)
   at org.infinispan.lucene.impl.InfinispanIndexOutput.close(InfinispanIndexOutput.java:176)
   at org.apache.lucene.index.CompoundFileWriter.close(CompoundFileWriter.java:218)
   at org.apache.lucene.index.DocumentsWriter.flush(DocumentsWriter.java:604)
   at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3587)
   at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3376)
   at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
   at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
   at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
   at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:158)
   at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:171)
   at org.hibernate.search.backend.impl.lucene.ExclusiveIndexWorkspaceImpl.afterTransactionApplied(ExclusiveIndexWorkspaceImpl.java:45)
   at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:124)
   at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
   at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:744)


The lock obtain exceptions are the following:

Code:
ERROR|2014-07-16 15:18:07,806|Hibernate Search: Index updates queue processor for index Cd-1|               LogErrorHandler - HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@10e45c53
Primary Failure:
   Entity Cd  Id 11435  Work Type  org.hibernate.search.backend.UpdateLuceneWork

org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@10e45c53
   at org.apache.lucene.store.Lock.obtain(Lock.java:84)
   at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1098)
   at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:146)
   at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:113)
   at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:117)
   at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:101)
   at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
   at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:744)
ERROR|2014-07-16 15:18:07,806|Hibernate Search: Index updates queue processor for index Cd-1|        LuceneBackendQueueTask - HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!


What do you mean if the errors happen if I disable CacheStore(s)? If you're referring to persistence, one of my requirements is to have persisted data, so I'm afraid it is a requirement.

Best Regards


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Thu Jul 17, 2014 8:58 am 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Quote:
What do you mean if the errors happen if I disable CacheStore(s)? If you're referring to persistence, one of my requirements is to have persisted data, so I'm afraid it is a requirement.

Yes I understand you want it ultimately enabled, but if you could experiment by running it without persistence, that would help to identify the fault.

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Thu Jul 17, 2014 9:08 am 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Ah, maybe I've seen what's wrong and it might not be related to persistence after all.

Could you make sure this option:
Quote:
hibernate.search.default.exclusive_index_use=true

is applied only to the Master node?

The slave nodes should set it to false.

Your error shows a lock timeout on acquisition of the indexwriter lock (the LockObtainFailedException), but having a single master this should never happen in practice are there is no contention at all. (The lock is designed to protect from mistakes in configuration, not strictly neccessary at runtime).

So another possible problem could be that you have multiple masters nodes, or multiple applications writing on the same index? That would explain it.

Also, keep in mind that unless you isolate the cluster groups, Infinispan will automatically connect to other servers running the same stack: make sure the index is not being "shared unintentionally" with different servers or development machines.

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Tue Apr 21, 2015 9:41 am 
Newbie

Joined: Tue Apr 21, 2015 9:23 am
Posts: 3
sanne.grinovero wrote:
Could you make sure this option:
Quote:
hibernate.search.default.exclusive_index_use=true

is applied only to the Master node?

The slave nodes should set it to false.

I'm also experiencing the LockObtainFailedException. If I use the "jgroups" (automatic master election) backend, I have to disable hibernate.search.default.exclusive_index_use. I can manually set up a master and a slave ("jgroupsMaster" and "jgroupsSlave" with hibernate.search.default.exclusive_index_use enabled and disabled, respectively). So it seems like I can choose between a) performance at the cost of statically assigning a master or b) automatic master election at the cost of performance. I would like the automatic master election without the performance penalty. Is it possible?

The Lucene directory provider is Infinispan with replicated caches that (currently) uses file-store. The system is using WildFly 8.2 with Lucene 3.6.2, Hibernate Search 4.5.1, Infinispan 6.0.2, and JGroups 3.4.5.

Hibernate Search settings wrote:
<!-- Enable cluster-replicated index, but the default configuration does not enable any form of permanent persistence for the index -->
<property name="hibernate.search.default.directory_provider" value="infinispan"/>

<!-- Use CacheManager defined in WildFly configuration file, e.g., standalone.xml -->
<property name="hibernate.search.infinispan.cachemanager_jndiname" value="java:jboss/infinispan/container/hibernate-search"/>

<!-- The default TransactionalWorker wrapped by com.apc.config.hibersync.server.services.IServerServiceLocator.[startCurrentRequest|endCurrentRequest] -->
<property name="hibernate.search.worker.scope" value="com.apc.config.hibersync.server.hsearch.backed.InRequestContextTransactionalWorker"/>

<!-- Automatic master election via JGroups, requires Infinispan directory provider -->
<property name="hibernate.search.default.worker.backend" value="jgroups"/>

<property name="hibernate.search.services.jgroups.configurationFile" value="flush-tcp.xml"/> <!-- TODO: Use the JGroups default stack in standalone.xml -->

<property name="hibernate.search.default.exclusive_index_use" value="false"/> <!-- To avoid LockObtainFailedException -->

<property name="hibernate.search.analyzer" value="org.apache.lucene.analysis.standard.ClassicAnalyzer"/>

WildFly configuration wrote:
<cache-container name="hibernate-search" start="EAGER" jndi-name="java:jboss/infinispan/container/hibernate-search">
<transport lock-timeout="330000"/>
<replicated-cache name="LuceneIndexesMetadata" start="EAGER" mode="SYNC" remote-timeout="330000">
<locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
<transaction mode="NONE"/>
<eviction strategy="NONE" max-entries="-1"/>
<expiration max-idle="-1"/>
<state-transfer enabled="true" timeout="480000"/>
<indexing index="NONE"/>
<file-store preload="true" purge="false" passivation="false" relative-to="dco.data.dir" path="lucene/indexes">
<write-behind/>
</file-store>
</replicated-cache>

<replicated-cache name="LuceneIndexesData" start="EAGER" mode="SYNC" remote-timeout="25000">
<locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
<transaction mode="NONE"/>
<eviction strategy="NONE" max-entries="-1"/>
<expiration max-idle="-1"/>
<state-transfer enabled="true" timeout="480000"/>
<indexing index="NONE"/>
<file-store preload="true" purge="false" passivation="false" relative-to="dco.data.dir" path="lucene/indexes">
<write-behind/>
</file-store>
</replicated-cache>

<replicated-cache name="LuceneIndexesLocking" start="EAGER" mode="SYNC" remote-timeout="25000">
<locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
<transaction mode="NONE"/>
<eviction strategy="NONE" max-entries="-1"/>
<expiration max-idle="-1"/>
<state-transfer enabled="true" timeout="480000"/>
<indexing index="NONE"/>
</replicated-cache>

</cache-container>


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Tue Apr 21, 2015 9:51 am 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Hi,
Quote:
So it seems like I can choose between a) performance at the cost of statically assigning a master or b) automatic master election at the cost of performance. I would like the automatic master election without the performance penalty. Is it possible?


Not with the current code. We're working on that, but the automatic master election in Hibernate Search 4 is highly experimental (backend "jgroups").

Disabling the backend and resorting to disabling "exclusive_index_use" is generally a bad idea, I'd only recommend that if you have guarantees that only one node will ever write: otherwise you risk facing the LockObtainFailedException.

I would suggest to upgrade to Hibernate Search 5.1+ and Infinispan 7.1+ : the better automatic master election wasn't implemented in those versions either, but it should then be easier to upgrade.
Is there anything preventing you from upgrading?

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Tue Apr 21, 2015 10:03 am 
Newbie

Joined: Tue Apr 21, 2015 9:23 am
Posts: 3
sanne.grinovero wrote:
Hi,
Quote:
So it seems like I can choose between a) performance at the cost of statically assigning a master or b) automatic master election at the cost of performance. I would like the automatic master election without the performance penalty. Is it possible?


Not with the current code. We're working on that, but the automatic master election in Hibernate Search 4 is highly experimental (backend "jgroups").

Disabling the backend and resorting to disabling "exclusive_index_use" is generally a bad idea, I'd only recommend that if you have guarantees that only one node will ever write: otherwise you risk facing the LockObtainFailedException.

I would suggest to upgrade to Hibernate Search 5.1+ and Infinispan 7.1+ : the better automatic master election wasn't implemented in those versions either, but it should then be easier to upgrade.
Is there anything preventing you from upgrading?

Thank you for the very quick answer. We are running WildFly 8.2 (with a lot of specific versions being pulled in: https://repo1.maven.org/maven2/org/wildfly/wildfly-parent/8.2.0.Final/wildfly-parent-8.2.0.Final.pom) but if Hibernate Search 5.1+ is able to play nice with Hibernate 4, I guess we can upgrade. I will have to look into that, taking a quick look we may only need to upgrade Hibernate from 4.3.7 (in WildFly 8.2) to 4.3.8 or later.

However, if the master election is still experimental in Hibernate Search 5.1, maybe we should consider another way entirely. Not having to manually select a master would be nice.


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Tue Apr 21, 2015 10:09 am 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Yes Hibernate Search 5 is compatible with the same versions of Hibernate ORM as Hibernate Search 4.3.x (in other words, compatible with WildFly 8.0, 8.1, 8.2 and 9.0)
The big change is that it's based on Lucene 4, which is why I suggest to keep up to date: Lucene 4 is significantly different than Lucene 3 and if you invest too much in customizations, it will be harder later to switch to Lucene 4 (or Lucene 5, which is similar to 4).

The migration guide:
http://hibernate.org/search/documentation/migrate/5.0/

Quote:
However, if the master election is still experimental in Hibernate Search 5.1, maybe we should consider another way entirely. Not having to manually select a master would be nice.

Yes I'm open to alternative ideas; one of them would be to broadcast the log of events to all nodes and have each of them apply the changes to a local index. It's likely we'll implement a reliable master election in the short term though, as the log approach sounds better but will take some months.

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Wed Apr 22, 2015 3:24 am 
Newbie

Joined: Tue Apr 21, 2015 9:23 am
Posts: 3
sanne.grinovero wrote:
Yes Hibernate Search 5 is compatible with the same versions of Hibernate ORM as Hibernate Search 4.3.x (in other words, compatible with WildFly 8.0, 8.1, 8.2 and 9.0)
The big change is that it's based on Lucene 4, which is why I suggest to keep up to date: Lucene 4 is significantly different than Lucene 3 and if you invest too much in customizations, it will be harder later to switch to Lucene 4 (or Lucene 5, which is similar to 4).

The migration guide:
http://hibernate.org/search/documentation/migrate/5.0/

Quote:
However, if the master election is still experimental in Hibernate Search 5.1, maybe we should consider another way entirely. Not having to manually select a master would be nice.

Yes I'm open to alternative ideas; one of them would be to broadcast the log of events to all nodes and have each of them apply the changes to a local index. It's likely we'll implement a reliable master election in the short term though, as the log approach sounds better but will take some months.
We will perform some tests using 2 nodes with backend "jgroups" and exclusive_index_use "false" and see what happens. Upgrading should be possible but since there seems to be no short-term gains (I know you wrote that you are likely to implement/complete the master election on the short term but I also imagine that you and your team have a lot on your plate), we want to see how far the current version can take us. I will definitely keep in mind not to do too much work on Lucene 3 since Lucene 4 is quite different.


Top
 Profile  
 
 Post subject: Re: Hibernate Search: Timeout Exception when using Infinispan
PostPosted: Wed Apr 22, 2015 4:33 am 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Seems a sensible plan!
Thanks for all comments, please keep the feedback coming.
However keep in mind that this jgroups backend is quite experimental: I don't think it's widely used (nor known) by typical users, it was created mainly to accommodate for the needs for a platform being built on top of this, but I know they inject a custom Channel and are quite expert in configuring JGroups to their needs. It works well for them - other than that, I'm happy to help if I can.

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 11 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.