[JBoss JIRA] (ISPN-3655) Default optimistic locking configuration leads to inconsistency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3655?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3655:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024373
> Default optimistic locking configuration leads to inconsistency
> ---------------------------------------------------------------
>
> Key: ISPN-3655
> URL: https://issues.jboss.org/browse/ISPN-3655
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Locking and Concurrency, Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: jdg620_dm, jdg62GAblocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> Infinispan transactional caches are configured with optimistic locking by default. Without extra configuration (REPETEABLE_READ + writeSkews), concurrent replace() calls will return true under contention and transactions will commit.
> Under contention, even if replace() returns true for multiple resources, it should rollback all except one transaction.
> When transactional optimistic locking is enabled (default), it should enable all options required to make this scenarios correct.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3655) Default optimistic locking configuration leads to inconsistency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3655?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3655:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 1024373|https://bugzilla.redhat.com/show_bug.cgi?id=1024373]
This should be mentioned in release notes as a fixed issue so that users know about it.
> Default optimistic locking configuration leads to inconsistency
> ---------------------------------------------------------------
>
> Key: ISPN-3655
> URL: https://issues.jboss.org/browse/ISPN-3655
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Locking and Concurrency, Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: jdg620_dm, jdg62GAblocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> Infinispan transactional caches are configured with optimistic locking by default. Without extra configuration (REPETEABLE_READ + writeSkews), concurrent replace() calls will return true under contention and transactions will commit.
> Under contention, even if replace() returns true for multiple resources, it should rollback all except one transaction.
> When transactional optimistic locking is enabled (default), it should enable all options required to make this scenarios correct.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3589:
--------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> StackOverflow in InternalMetadataImpl.Externalizer
> --------------------------------------------------
>
> Key: ISPN-3589
> URL: https://issues.jboss.org/browse/ISPN-3589
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Mircea Markus
> Labels: jdg620_dm, jdg62GAblocker
>
> the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in:
> {code}
> metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte
> rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl
> {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal
> MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act
> ual=InternalMetadataImpl [....]
> {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
10 years, 6 months
[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3633:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> InvalidateL1Command during ST should not cancel writing the entry by ST
> -----------------------------------------------------------------------
>
> Key: ISPN-3633
> URL: https://issues.jboss.org/browse/ISPN-3633
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: jdg620_dm, jdg62GAblocker
> Fix For: 6.0.0.Final
>
>
> When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry.
> Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3645) StateTransferLargeObjectTest hangs randomly
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3645?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3645:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> StateTransferLargeObjectTest hangs randomly
> -------------------------------------------
>
> Key: ISPN-3645
> URL: https://issues.jboss.org/browse/ISPN-3645
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 6.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: jdg620_dm, jdg62GAblocker
> Fix For: 6.0.0.CR2
>
> Attachments: stlot.stack
>
>
> StateTransferLargeObject sometimes hangs in the second part of the test, when it checks that all the nodes in the cluster can read the inserted values. I was able to make it hang reliably when run separately, by increasing the number of keys from 1000 to 5000.
> The cause is probably JGRP-1675, as many OOB threads appear to be stuck in FlowControl.decrementIfEnoughCredits.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3655) Default optimistic locking configuration leads to inconsistency
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3655?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3655:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> Default optimistic locking configuration leads to inconsistency
> ---------------------------------------------------------------
>
> Key: ISPN-3655
> URL: https://issues.jboss.org/browse/ISPN-3655
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Locking and Concurrency, Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: jdg620_dm, jdg62GAblocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> Infinispan transactional caches are configured with optimistic locking by default. Without extra configuration (REPETEABLE_READ + writeSkews), concurrent replace() calls will return true under contention and transactions will commit.
> Under contention, even if replace() returns true for multiple resources, it should rollback all except one transaction.
> When transactional optimistic locking is enabled (default), it should enable all options required to make this scenarios correct.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3657) L1WriteSynchronizer exception on L1 write race
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3657?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3657:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> L1WriteSynchronizer exception on L1 write race
> ----------------------------------------------
>
> Key: ISPN-3657
> URL: https://issues.jboss.org/browse/ISPN-3657
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Labels: jdg620_dm, jdg62GAblocker
> Fix For: 6.0.0.Final
>
>
> {noformat}java.lang.IllegalStateException: There is already a L1WriteSynchronizer associated with key: *|tempIndexName
> at org.infinispan.distribution.L1ManagerImpl.registerL1WriteSynchronizer(L1ManagerImpl.java:278)
> at org.infinispan.interceptors.distribution.L1NonTxInterceptor.performL1Lookup(L1NonTxInterceptor.java:109)
> at org.infinispan.interceptors.distribution.L1NonTxInterceptor.performCommandWithL1WriteIfAble(L1NonTxInterceptor.java:88)
> at org.infinispan.interceptors.distribution.L1NonTxInterceptor.visitGetKeyValueCommand(L1NonTxInterceptor.java:76)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:113)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> 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.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitGetKeyValueCommand(NonTransactionalLockingInterceptor.java:34)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> 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.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> 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.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:237)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> at org.infinispan.CacheImpl.get(CacheImpl.java:368)
> at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
> at org.infinispan.lucene.impl.FileListOperations.getFileList(FileListOperations.java:43)
> at org.infinispan.lucene.impl.DirectoryImplementor.fileExists(DirectoryImplementor.java:64)
> at org.infinispan.lucene.impl.DirectoryLuceneV3.fileExists(DirectoryLuceneV3.java:72)
> at org.apache.lucene.index.SegmentInfo.addIfExists(SegmentInfo.java:637)
> at org.apache.lucene.index.SegmentInfo.files(SegmentInfo.java:662)
> at org.apache.lucene.index.SegmentInfos.files(SegmentInfos.java:851)
> at org.apache.lucene.index.IndexFileDeleter.incRef(IndexFileDeleter.java:480)
> at org.apache.lucene.index.IndexFileDeleter.checkpoint(IndexFileDeleter.java:453)
> at org.apache.lucene.index.IndexWriter.checkpoint(IndexWriter.java:3039)
> at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3591)
> 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.infinispan.lucene.profiling.LuceneWriterThread.testLoop(LuceneWriterThread.java:40){noformat}
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3659) Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3659?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3659:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3659
> URL: https://issues.jboss.org/browse/ISPN-3659
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: jdg620_dm, jdg62GAblocker
> Fix For: 6.1.0.Final
>
>
> The fix for ISPN-2372 was incomplete. We now clear the references from the thread-local marshallers to the cache itself, so it can be garbage-collected, but we don't clear the marshallers or their instance caches. If the cache values' object graph is very large, the cached marshallers will use up a lot of memory that could be garbage-collected (assuming the cache was indeed restarted and only one cache instance is running now).
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3665:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: jdg620_dm, jdg62GAblocker
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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
10 years, 6 months