[JBoss JIRA] (ISPN-3655) Default optimistic locking configuration leads to inconsistency
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3655?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3655:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2177
> 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
> 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
11 years, 2 months
[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3422:
-----------------------------------
I have a feeling (already mentioned in ISPN-3600) that the ignorePreviousValue is rather abused, as even with the flag set we would do the comparison, and with the flag set to false on non-origin nodes the command is ignored at all in perform()... I know this is an implementation detail, but the flag name does not correspond to the use at all.
ad 1) I don't quite understand the problem - conditional commands already require equals implementation on values or defined valueEquivalence within the command
> In non-tx caches, write operations may not be atomic during rebalance
> ---------------------------------------------------------------------
>
> Key: ISPN-3422
> URL: https://issues.jboss.org/browse/ISPN-3422
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification.
> Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible:
> {code}
> thread 1: putIfAbsent(k, v1) -> null
> thread 2: putIfAbsent(k, v2) -> null
> {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
11 years, 2 months
[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3422:
------------------------------------
Yes, we should be able to fix this by comparing the PutIfAbsentCommand's value with the value that exists in the data container even when ignorePreviousValue is set to true. If the value in the data container is either null or the same, then the command should succeed, otherwise it should fail.
I didn't implement this back when fixing ISPN-3357 because of 2 reasons:
1) Values would have to implement equals() for this to work. AFAICT we don't really support versioning in non-tx mode.
2) We should only do the comparison check on the primary, because we want the final value to be the same on all the owners even if there was an inconsistency before. So we'd need to inject a {{ClusteringDependentLogic}} in all the conditional commands.
> In non-tx caches, write operations may not be atomic during rebalance
> ---------------------------------------------------------------------
>
> Key: ISPN-3422
> URL: https://issues.jboss.org/browse/ISPN-3422
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification.
> Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible:
> {code}
> thread 1: putIfAbsent(k, v1) -> null
> thread 2: putIfAbsent(k, v2) -> null
> {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
11 years, 2 months
[JBoss JIRA] (ISPN-3618) Cannot retrieve evicted entries from Microsoft SQL Server 2012/2008R2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3618?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3618:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> made a comment on [bug 1018227|https://bugzilla.redhat.com/show_bug.cgi?id=1018227]
> Cannot retrieve evicted entries from Microsoft SQL Server 2012/2008R2
> ---------------------------------------------------------------------
>
> Key: ISPN-3618
> URL: https://issues.jboss.org/browse/ISPN-3618
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores, Server
> Affects Versions: 6.0.0.CR1
> Reporter: Jakub Markos
> Assignee: Mircea Markus
> Attachments: server_mssql2012_mysql55.log.zip
>
>
> When using this configuration:
> {code:xml}
> <local-cache name="default" start="EAGER" batching="false">
> <locking isolation="READ_COMMITTED" acquire-timeout="20000" concurrency-level="500" striping="false" />
> <transaction mode="NONE" />
> <eviction strategy="LRU" max-entries="2"/>
> <string-keyed-jdbc-store name="defaultStoreName" datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="true" purge="false">
> <string-keyed-table prefix="EDG_STRING">
> <id-column name="id" type="VARCHAR(255)"/>
> <data-column name="datum" type="VARBINARY(1000)"/>
> <timestamp-column name="version" type="BIGINT"/>
> </string-keyed-table>
> </string-keyed-jdbc-store>
> </local-cache>
> {code}
> and running this code:
> {code}
> RemoteCache<Object, Object> cache = new RemoteCacheManager(conf).getCache();
> cache.clear();
> cache.put(new Double(10), new Double(10));
> cache.put(new Double(20), new Double(20));
> cache.put(new Double(30), new Double(30)); // key 10 is evicted
> System.out.println(cache.get(new Double(10)));
> System.out.println(cache.get(new Double(20)));
> System.out.println(cache.get(new Double(30)));
> {code}
> output:
> {quote}
> null
> 20.0
> 30.0
> {quote}
> Attached are logs for mssql2012 and mysql55 (where it works).
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3655) Default optimistic locking configuration leads to inconsistency
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3655?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3655 started by Galder Zamarreño.
> 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
> 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
11 years, 2 months
[JBoss JIRA] (ISPN-3655) Default optimistic locking configuration leads to inconsistency
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3655?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño reassigned ISPN-3655:
--------------------------------------
Assignee: Galder Zamarreño (was: Mircea Markus)
> 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
> 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
11 years, 2 months
[JBoss JIRA] (ISPN-3657) L1WriteSynchronizer exception on L1 write race
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3657?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3657:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2175
> 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
> 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
11 years, 2 months