[JBoss JIRA] (ISPN-1990) Preload sets the versions to null (repeatable read + write skew)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1990?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-1990:
--------------------------------
Assignee: Galder Zamarreño (was: Mircea Markus)
> Preload sets the versions to null (repeatable read + write skew)
> ----------------------------------------------------------------
>
> Key: ISPN-1990
> URL: https://issues.jboss.org/browse/ISPN-1990
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.1.3.FINAL
> Environment: Java 6 (64bits)
> Infinispan 5.2.0-SNAPSHOT
> MacOS
> Reporter: Pedro Ruivo
> Assignee: Galder Zamarreño
> Labels: preload, skew, versioning, write
> Fix For: 5.3.0.Final
>
>
> I think I've spotted a issue when I use repeatable read with write skew check and I preload the cache.
>
> I've made a test case to reproduce the bug. It can be found here [1].
> The problem is that each keys preloaded is put in the container with version = null. When I try to commit a transaction, I get this exception:
>
> {code}
> java.lang.IllegalStateException: Entries cannot have null versions!
> at org.infinispan.container.entries.ClusteredRepeatableReadEntry.performWriteSkewCheck(ClusteredRepeatableReadEntry.java:44)
> at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:81)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AllNodesLogic.createNewVersionsAndCheckForWriteSkews(ClusteringDependentLogic.java:133)
> at org.infinispan.interceptors.VersionedEntryWrappingInterceptor.visitPrepareCommand(VersionedEntryWrappingInterceptor.java:64)
> {code}
>
> I think that all info is in the test case, but if you need something let
> me know.
>
> Cheers,
> Pedro
> [1]
> https://github.com/pruivo/infinispan/blob/issue_1/core/src/test/java/org/...
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-1990) Preload sets the versions to null (repeatable read + write skew)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1990?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-1990:
--------------------------------
Fix Version/s: 5.2.1
> Preload sets the versions to null (repeatable read + write skew)
> ----------------------------------------------------------------
>
> Key: ISPN-1990
> URL: https://issues.jboss.org/browse/ISPN-1990
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.1.3.FINAL
> Environment: Java 6 (64bits)
> Infinispan 5.2.0-SNAPSHOT
> MacOS
> Reporter: Pedro Ruivo
> Assignee: Galder Zamarreño
> Labels: preload, skew, versioning, write
> Fix For: 5.2.1, 5.3.0.Final
>
>
> I think I've spotted a issue when I use repeatable read with write skew check and I preload the cache.
>
> I've made a test case to reproduce the bug. It can be found here [1].
> The problem is that each keys preloaded is put in the container with version = null. When I try to commit a transaction, I get this exception:
>
> {code}
> java.lang.IllegalStateException: Entries cannot have null versions!
> at org.infinispan.container.entries.ClusteredRepeatableReadEntry.performWriteSkewCheck(ClusteredRepeatableReadEntry.java:44)
> at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:81)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AllNodesLogic.createNewVersionsAndCheckForWriteSkews(ClusteringDependentLogic.java:133)
> at org.infinispan.interceptors.VersionedEntryWrappingInterceptor.visitPrepareCommand(VersionedEntryWrappingInterceptor.java:64)
> {code}
>
> I think that all info is in the test case, but if you need something let
> me know.
>
> Cheers,
> Pedro
> [1]
> https://github.com/pruivo/infinispan/blob/issue_1/core/src/test/java/org/...
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-1841) Write skew checks are performed on all entries in a transaction context
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1841?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-1841:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
(was: 6.0.0.Final)
> Write skew checks are performed on all entries in a transaction context
> -----------------------------------------------------------------------
>
> Key: ISPN-1841
> URL: https://issues.jboss.org/browse/ISPN-1841
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.6.FINAL
> Reporter: Manik Surtani
> Assignee: Mircea Markus
> Fix For: 5.2.1, 5.3.0.Final
>
>
> They should only be performed on entries that are read first and then updated. The current implementation doesn't cause any problems, however it is unnecessary processing and certain transactions may unnecessarily abort if, for example, an entry is read, and not written to, but the entry changes before the transaction commits.
> From Pedro Ruivo's email to infinispan-dev, where this was reported:
> {quote}
> I've noticed that in the last version (5.1.x) the write skew check is
> performed on all keys written. However, from your documentation [1] I
> understood that the write skew was meant to be performed only on the
> written keys that were previously read.
> Is this change intentional?
> Cheers,
> Pedro Ruivo
> [1] https://docs.jboss.org/author/display/ISPN51/Data+Versioning
> "Write skew checks are performed at prepare-time to ensure a concurrent
> transaction hasn't modified an entry while it was read and potentially
> updated based on the value read."
> {quote}
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2173:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
(was: 6.0.0.Final)
> NPE when using XA enlistment without recovery
> ---------------------------------------------
>
> Key: ISPN-2173
> URL: https://issues.jboss.org/browse/ISPN-2173
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Labels: jdg6
> Fix For: 5.2.1, 5.3.0.Final
>
>
> When using xa enlistment (transaction/useSynchronization=false, default), and recovery is disabled (transaction/recovery/enabled=false, default) the transaction manager might invoke recovery related methods such as XAResource.forget() in certain situations.
> E.g. the JBossTM invokes "forget", if during, XAResource.commit(xid, true) (second param means 1PC=true) an exception is thrown. (I expect an XAResource.rollback to be invoked in between the failed commit and forget).
> Here is such a stack trace:
> {quote}
> 2012-07-25 14:13:42,821 WARN (testng-CheckRemoteLockAcquiredOnlyOnceDistTest:) [org.infinispan.transaction.xa.TransactionXaAdapter] Exception removing recovery information:java.lang.NullPointerException
> at org.infinispan.transaction.xa.TransactionXaAdapter.forget(TransactionXaAdapter.java:159)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.forget(XAResourceRecord.java:759)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:691)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2285)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1468)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenOperation(CheckRemoteLockAcquiredOnlyOnceTest.java:157)
> at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenPutAll(CheckRemoteLockAcquiredOnlyOnceTest.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {quote}
> As we do allow xa enlistment *without* recovery enabled this NPE shouldn't be shown to the user.
> Instead an warning should be logged stating that XA enlistment is configured without recovery, but recovery might be needed in certain situations.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2013) Using explicit "unlock" causes TimeoutException for other Threads
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2013:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
(was: 6.0.0.Final)
> Using explicit "unlock" causes TimeoutException for other Threads
> -----------------------------------------------------------------
>
> Key: ISPN-2013
> URL: https://issues.jboss.org/browse/ISPN-2013
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.1.2.FINAL
> Environment: Windows 7 64-bit
> Reporter: Dmitry Udalov
> Assignee: Mircea Markus
> Fix For: 5.2.1, 5.3.0.Final
>
> Attachments: LockTest.java
>
>
> In a test I have several tasks that run on a single cache node configured as transactional pessimistic replicated cache. If I explicitly call "unlock" then I consistently see TimeoutException reported by some tasks. Without explicit "unlock" the test works fine. Does it mean that I should never call "unlock" and rely on transaction.commit/rollback ? It's seen with infinispan-5.1.2.FINAL
>
> Here's what in a nutshell each task does:
>
> final lockKey = ...
>
> executor.submit(new Callable<Boolean>() {
> public Boolean call() throws Exception
>
> TransactionManager tx = cache.getAdvancedCache().getTransactionManager();
> tx.begin()
> try {
> if ( lockManager.lock(lockKey) ) {
>
> // ...
>
> // removing next line makes test happy. Otherwise some tasks report TimeoutException (pls. see the stack traces)
> cache.getLockManager().unlock(lockKey);
> }
> } catch(Throwable t) {
> tx.setRollbackOnly();
> } finally {
> if (ut.getStatus() == Status.STATUS_ACTIVE)
> ut.commit();
> else
> ut.rollback();
> }
>
>
> By the time I received that exception all other tasks were completed and they released the lock on the key in question.
> I also see that LockManagerImpl.lock recognized that the lock was not owned by any thread - see "Lock held by [null]", which seems to be right. But yet the lock failed to be acquired.
> Is it a matter to trying it one more time?
>
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [foo] for requestor [GlobalTransaction:<Sound-15075>:8:local]! Lock held by [null]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:206)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:180)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:170)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:228)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:144)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:207)
> at org.infinispan.interceptors.StateTransferLockInterceptor.visitLockControlCommand(StateTransferLockInterceptor.java:138)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:94)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:484)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:468)
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2278) Implicit transaction enabling during configuration fails
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2278?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2278:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
(was: 6.0.0.Final)
> Implicit transaction enabling during configuration fails
> --------------------------------------------------------
>
> Key: ISPN-2278
> URL: https://issues.jboss.org/browse/ISPN-2278
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 5.1.6.FINAL
> Reporter: Thomas Fromm
> Assignee: Tristan Tarrant
> Fix For: 5.2.1, 5.3.0.Final
>
>
> The implicit enabling of transaction support does not work in all cases described in TransactionMode Javadoc inside the current configuration API.
> - transactionManagerLookup is explicit configured
> This works not in programmatic.
> - enabled batching
> When using XML configuration, this will not work, when only <invocationBatching> element and no <transaction> element is used.
> At ConfigurationBuilderHolder.newConfigurationBuilder(...) the default cache config is used as base for the new named cache. Since build() is called, the TransactionConfiguration is set to NON_TRANSACTIONAL in the Configuration template used for the new ConfigurationBuilder. Later then any if(transactionMode == null)-related conditions in TransactionConfigurationBuilder will fail.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-761:
-------------------------------
Fix Version/s: 5.3.0.Final
(was: 6.0.0.Final)
> Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
> -------------------------------------------------------------------------
>
> Key: ISPN-761
> URL: https://issues.jboss.org/browse/ISPN-761
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 4.2.0.BETA1
> Reporter: Paul Ferraro
> Assignee: Vladimir Blagojevic
> Labels: potential_performance_hit
> Fix For: 5.3.0.Final
>
>
> Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
> I think CacheLoaderInterceptor needs to implement the following methods:
> Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
> Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
> Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
> Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-761:
-------------------------------
Assignee: Galder Zamarreño (was: Vladimir Blagojevic)
> Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
> -------------------------------------------------------------------------
>
> Key: ISPN-761
> URL: https://issues.jboss.org/browse/ISPN-761
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 4.2.0.BETA1
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Labels: potential_performance_hit
> Fix For: 5.3.0.Final
>
>
> Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
> I think CacheLoaderInterceptor needs to implement the following methods:
> Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
> Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
> Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
> Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
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
13 years, 2 months