[JBoss JIRA] (ISPN-3149) Unexpected reporting of no live owners
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3149?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3149:
--------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Unexpected reporting of no live owners
> --------------------------------------
>
> Key: ISPN-3149
> URL: https://issues.jboss.org/browse/ISPN-3149
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.3.0.Beta2
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Minor
>
> Running a four node test with infinispan-server 5.3.0-SNAPSHOT
> produces following errors:
> {code}
> 08:46:22,962 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Starting StateTransferManager of cache testCache on node node01/default
> 08:46:22,969 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Installing new cache topology CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null} on cache testCache
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Received new topology for cache testCache, isRebalance = false, isMember = true, topology = CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null}
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (MSC service thread 1-3) Signalling topology 0 is installed
> 08:46:22,973 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) On cache testCache we have: added segments: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37]
> 08:46:22,974 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Adding inbound state transfer for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37] of cache testCache
> 08:46:22,974 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 0 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,975 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 1 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 2 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 3 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 4 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 5 of cache testCache. Current owners are:
> {code}
> all logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> configs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> infinispan-server build info:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3177) "Read past EOF" in case of using async fileStore with "infinispan" directory_provider
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3177?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3177:
--------------------------------
Fix Version/s: 6.0.0.Final
> "Read past EOF" in case of using async fileStore with "infinispan" directory_provider
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3177
> URL: https://issues.jboss.org/browse/ISPN-3177
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory, Querying
> Affects Versions: 5.2.4.Final
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Fix For: 6.0.0.Final
>
> Attachments: config.xml
>
>
> The cache configuration is attached (config.xml).
> While trying to run performance tests on the cache configured in the provided XML, i.e. performing parallel puts/gets with many threads (local mode), the following exception is thrown:
> Please note that exception is thrown on Put. I've changed the tests so that only one thread is run, but anyway this issue appears.
> If I comment the loader's part, then the test passes.
>
> {code}
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager query
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildIncrementalSearchFactory(SearchFactoryBuilder.java:169)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:149)
> at org.hibernate.search.impl.MutableSearchFactory.addClasses(MutableSearchFactory.java:194)
> at org.infinispan.query.backend.QueryInterceptor.enableClassesIncrementally(QueryInterceptor.java:225)
> at org.infinispan.query.backend.QueryInterceptor.updateKnownTypesIfNeeded(QueryInterceptor.java:250)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:426)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:128)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitPutKeyValueCommand(NonTransactionalLockingInterceptor.java:84)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infi^Cnispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:760)
> at org.infinispan.CacheImpl.put(CacheImpl.java:754)
> at org.infinispan.CacheImpl.put(CacheImpl.java:748)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:244)
> at org.radargun.cachewrappers.InfinispanExplicitLockingWrapper.put(InfinispanExplicitLockingWrapper.java:72)
> at org.radargun.cachewrappers.InfinispanQueryWrapper.put(InfinispanQueryWrapper.java:72)
> at org.radargun.stressors.StressTestStressor$FixedSetPerThreadOperationLogic.init(StressTestStressor.java:313)
> at org.radargun.stressors.StressTestStressor$Stressor.run(StressTestStressor.java:541)
> Caused by: org.hibernate.search.SearchException: Could not initialize index
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 33 more
> Caused by: java.io.IOException: Read past EOF
> at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77)
> at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:86)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157)
> ... 36 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3177) "Read past EOF" in case of using async fileStore with "infinispan" directory_provider
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3177?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3177:
--------------------------------
Assignee: Adrian Nistor (was: Mircea Markus)
> "Read past EOF" in case of using async fileStore with "infinispan" directory_provider
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3177
> URL: https://issues.jboss.org/browse/ISPN-3177
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory, Querying
> Affects Versions: 5.2.4.Final
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Attachments: config.xml
>
>
> The cache configuration is attached (config.xml).
> While trying to run performance tests on the cache configured in the provided XML, i.e. performing parallel puts/gets with many threads (local mode), the following exception is thrown:
> Please note that exception is thrown on Put. I've changed the tests so that only one thread is run, but anyway this issue appears.
> If I comment the loader's part, then the test passes.
>
> {code}
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager query
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildIncrementalSearchFactory(SearchFactoryBuilder.java:169)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:149)
> at org.hibernate.search.impl.MutableSearchFactory.addClasses(MutableSearchFactory.java:194)
> at org.infinispan.query.backend.QueryInterceptor.enableClassesIncrementally(QueryInterceptor.java:225)
> at org.infinispan.query.backend.QueryInterceptor.updateKnownTypesIfNeeded(QueryInterceptor.java:250)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:426)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:128)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitPutKeyValueCommand(NonTransactionalLockingInterceptor.java:84)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infi^Cnispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:760)
> at org.infinispan.CacheImpl.put(CacheImpl.java:754)
> at org.infinispan.CacheImpl.put(CacheImpl.java:748)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:244)
> at org.radargun.cachewrappers.InfinispanExplicitLockingWrapper.put(InfinispanExplicitLockingWrapper.java:72)
> at org.radargun.cachewrappers.InfinispanQueryWrapper.put(InfinispanQueryWrapper.java:72)
> at org.radargun.stressors.StressTestStressor$FixedSetPerThreadOperationLogic.init(StressTestStressor.java:313)
> at org.radargun.stressors.StressTestStressor$Stressor.run(StressTestStressor.java:541)
> Caused by: org.hibernate.search.SearchException: Could not initialize index
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 33 more
> Caused by: java.io.IOException: Read past EOF
> at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77)
> at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:86)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157)
> ... 36 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3202) Infinispan cachestores remove entries early when maxIdle used
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3202?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3202:
--------------------------------
Fix Version/s: 6.0.0.Final
> Infinispan cachestores remove entries early when maxIdle used
> -------------------------------------------------------------
>
> Key: ISPN-3202
> URL: https://issues.jboss.org/browse/ISPN-3202
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Environment: Linux: debian wheezy
> uname -a: Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
> JBoss: 7.1.2.Final
> Embedded cache using infinispan 5.2.6.Final jars included in WAR's WEB-INF/lib directory.
> Reporter: Ralph Jennings
> Assignee: Mircea Markus
> Labels: cache-store, maxIdle, timeout
> Fix For: 6.0.0.Final
>
>
> When adding an entry to the cache (embedded), specifying maxIdle... The entry goes into the store, but the store removes the entry when maxIdle time elapses from creation (rather than from last access).
> The cache correctly keeps the entry in memory (unless evicted).
> This leaves the cache and store out of sync.
> I saw this same behavior with both stringKeyedJdbcStore and fileStore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3203) Infinispan cache index not loading initial data
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3203?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3203:
--------------------------------
Fix Version/s: 6.0.0.Final
> Infinispan cache index not loading initial data
> -----------------------------------------------
>
> Key: ISPN-3203
> URL: https://issues.jboss.org/browse/ISPN-3203
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Environment: Linux: debian wheezy
> uname -a: Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
> JBoss: 7.1.2.Final
> Embedded cache using infinispan 5.2.6.Final jars included in WAR's WEB-INF/lib directory.
> Reporter: Ralph Jennings
> Assignee: Adrian Nistor
> Labels: cache-store, index, infinispan, preload
> Fix For: 6.0.0.Final
>
>
> If you create a cache with an existing store to preload data from, the data is available to the cache (get and keySet works) but not to the index (no cache queries work).
> Only entries put into the cache after it starts up can be seen by the index.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3203) Infinispan cache index not loading initial data
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3203?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3203:
--------------------------------
Assignee: Adrian Nistor (was: Mircea Markus)
> Infinispan cache index not loading initial data
> -----------------------------------------------
>
> Key: ISPN-3203
> URL: https://issues.jboss.org/browse/ISPN-3203
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Environment: Linux: debian wheezy
> uname -a: Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
> JBoss: 7.1.2.Final
> Embedded cache using infinispan 5.2.6.Final jars included in WAR's WEB-INF/lib directory.
> Reporter: Ralph Jennings
> Assignee: Adrian Nistor
> Labels: cache-store, index, infinispan, preload
>
> If you create a cache with an existing store to preload data from, the data is available to the cache (get and keySet works) but not to the index (no cache queries work).
> Only entries put into the cache after it starts up can be seen by the index.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3229) L1 cache entries should not be passivated
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3229?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3229:
--------------------------------
Fix Version/s: 6.0.0.Final
> L1 cache entries should not be passivated
> -----------------------------------------
>
> Key: ISPN-3229
> URL: https://issues.jboss.org/browse/ISPN-3229
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: DistSyncL1PassivationFuncTest.java
>
>
> L1 entries are stored in the same data container as the real entries. These can be evicted which is fine, however we don't want them to be passivated as this could be costly to write/read from the cache store. We should either prevent L1 cache entries from being passivated or have an option to allow for it.
> Currently L1 entries are not differentiated from other entries except through the fact that they are mortal, which is used for other operations as well, which means they would need a placeholder of some kind to tell the container this is a L1 entry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3281) Deadlock in non-transactional caches during rebalance
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3281?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3281:
--------------------------------
Priority: Critical (was: Major)
> Deadlock in non-transactional caches during rebalance
> -----------------------------------------------------
>
> Key: ISPN-3281
> URL: https://issues.jboss.org/browse/ISPN-3281
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 6.0.0.Final
>
>
> Say we have a cache with node A and node B joins. The cache topology id is 1, primary_owner(k) = A in the current CH and primary_owner(k) = B in the pending CH.
> 1. Node A starts a put(k, v) command during the rebalance. It thinks it's the primary owner, so it acquires the lock locally and it forwards the command to B.
> 2. B installs topology 2, primary_owner(k) = B in the current CH, and there is no pending CH.
> 3. B receives the put(k, v) command from A. It thinks it's the primary owner, so it acquires the lock locally and it forwards the command to A.
> 4. A receives the put(k, v) command from B. Again it thinks it's the primary owner and tries to acquire the lock locally, but it times out because the lock is held by another thread (from step 1).
> I think it may be enough to update the topology id in the put(k, v) command on node B, before forwarding it back to A. That way, the command will block on node A until topology 2 is installed, and it won't try to lock the key again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3266:
--------------------------------
Affects Version/s: 5.3.0.Final
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: Mircea Markus
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3266:
--------------------------------
Fix Version/s: 6.0.0.Final
> Pessimistic Force Write Lock doesn't acquire remote lock
> --------------------------------------------------------
>
> Key: ISPN-3266
> URL: https://issues.jboss.org/browse/ISPN-3266
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: DistSyncL1PessimisticFuncTest.java
>
>
> Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism.
> This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months