[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated ISPN-4599:
----------------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> InfinispanIndexManager locks held when primary node change
> ----------------------------------------------------------
>
> Key: ISPN-4599
> URL: https://issues.jboss.org/browse/ISPN-4599
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Given the following configuration:
> {code:xml}
> <cache-container name="store" default-cache="default" statistics="true">
> <transport cluster="Infinispan-Query-Cluster"/>
> <!-- *************************************** -->
> <!-- Default Cache, with indexing enabled. -->
> <!-- *************************************** -->
> <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true">
> <indexing index="LOCAL">
> <property name="hibernate.search.default.indexmanager">
> org.infinispan.query.indexmanager.InfinispanIndexManager
> </property>
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> </indexing>
> </replicated-cache>
> <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </distributed-cache>
> <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000">
> <indexing index="NONE"/>
> </replicated-cache>
> </cache-container>
> {code}
> Scenario:
> - Start Node 1
> - Insert a few @Indexed objects in the cache
> - Start Node 2
> - Insert a few @Indexed objects in the cache
> Node 2 cannot acquire the locks to write and throws errors:
> {code}
> org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates
> ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException
> ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f
> {code}
> During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking.
> When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5379?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5379:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1212505|https://bugzilla.redhat.com/show_bug.cgi?id=1212505] from ON_QA to VERIFIED
> Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5379
> URL: https://issues.jboss.org/browse/ISPN-5379
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Beta3
>
>
> From Dennis Reed:
> A ConcurrentModificationException in the CacheWriter interceptor during a commit.
> java.util.ConcurrentModificationException
> at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953)
> at java.util.LinkedList$ListItr.next(LinkedList.java:886)
> at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210)
> at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115)
> The code is looping through the modifications associated with the transaction:
> List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications();
> ...
> 210: for (WriteCommand cacheCommand : modifications) {
> The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer".
> But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification?
> Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (ISPN-5691) Server should enable writeSkew for some configurations by default
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5691?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5691:
----------------------------------
Fix Version/s: 7.2.6.Final
(was: 7.2.5.Final)
> Server should enable writeSkew for some configurations by default
> -----------------------------------------------------------------
>
> Key: ISPN-5691
> URL: https://issues.jboss.org/browse/ISPN-5691
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Fix For: 8.1.0.Final, 7.2.6.Final
>
>
> By default, optimistic locking caches do not enable write skew. This was already spotted in ISPN-3655.
> In an embedded environment, the user can always enable write skew in its configuration, but this cannot be enabled in server mode.
> Widlfly does enable write skew programmatically depending on the configuration:
> {quote}
> > hey, quick q: can you configure writeSkew on infinispan wildfly
> config?
> <pferraro> we always enable write skew for synchronous, optimistic,
> repeatable-read caches, and disable otherwise
> > pferraro: ah, you do it in the integration code?
> <pferraro> yes
> {quote}
> We need to be doing the same in server configuration, otherwise we run the risk of having issues with conditional operations under failure situations (see ISPN-2956)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months