[JBoss JIRA] (ISPN-3029) IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3029?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3029:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
> -----------------------------------------------------------------
>
> Key: ISPN-3029
> URL: https://issues.jboss.org/browse/ISPN-3029
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.5.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: onboard
> Fix For: 6.0.0.Alpha3, 6.0.0.Final
>
>
> Most LockSupportCacheStore methods that call {{acquireGlobalLock()}} ignore its return value and proceed as if the lock was acquired on all the buckets. ISPN-2378 partially fixed this by only attempting to unlock the global lock if the lock was actually acquired, but the processing that was supposed to be protected by the global lock is still executed even if the lock acquisition failed.
> In {{loadAllKeys}}, this doesn't usually cause any problems. But if the cache store contains expired entries, it will try to upgrade a bucket lock to a write lock in order to update the bucket on disk, and the upgrade will fail with a IllegalMonitorStateException:
> {noformat}
> > 20:41:36,960 ERROR [org.infinispan.statetransfer.OutboundTransferTask] (undefined) Failed to execute outbound transfer: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
> > at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883) [rt.jar:1.7.0_09-icedtea]
> > at org.infinispan.util.concurrent.locks.StripedLock.upgradeLock(StripedLock.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.LockSupportCacheStore.upgradeLock(LockSupportCacheStore.java:106) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore.access$000(BucketBasedCacheStore.java:49) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore$CollectionGeneratingBucketHandler.handle(BucketBasedCacheStore.java:159) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.file.FileCacheStore.loopOverBuckets(FileCacheStore.java:102) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore.loadAllKeysLockSafe(BucketBasedCacheStore.java:219) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.LockSupportCacheStore.loadAllKeys(LockSupportCacheStore.java:179) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AbstractDelegatingStore.loadAllKeys(AbstractDelegatingStore.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AsyncStore.loadKeys(AsyncStore.java:184) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AsyncStore.loadAllKeys(AsyncStore.java:205) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:163) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-2.jar:2.0.0.GA-redhat-2]
> {noformat}
> A simple solution would be to throw an exception any time the global lock acquisition failed, but the current global lock acquisition algorithm might need to change because it seems very deadlock-prone at the moment.
--
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, 7 months
[JBoss JIRA] (ISPN-3357) Insufficient owners with putIfAbsent during rebalance
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3357?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3357:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.2.8.Final
6.0.0.Alpha3
Resolution: Done
> Insufficient owners with putIfAbsent during rebalance
> -----------------------------------------------------
>
> Key: ISPN-3357
> URL: https://issues.jboss.org/browse/ISPN-3357
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.4.Final, 6.0.0.Alpha1
> Reporter: Takayoshi Kimura
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.2.8.Final, 6.0.0.Alpha3
>
> Attachments: 7c29bccb.log, ISPN-3357-full-logs-leave.zip
>
>
> Here is test scenario:
> * DIST numOwners=2, start with 3 nodes cluster then join 1 node during load
> * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total
> After the test run, the numberOfEntries on each node are:
> * node1: 20074
> * node2: 19888
> * node3: 20114
> * node4: 18885
> Total is 78961, 1039 entries are missing. No error on HotRod client side so 80000 entries should be there.
> Let's take a look at example missing entry, hash(thread01key151) = 7c29bccb.
> Current CH: owners(7c29bccb) are [node1, node2]
> Pending CH: owners(7c29bccb) are [node1, node2, node4]
> Balanced CH: owners(7c29bccb) are [node1, node4]
> The events sequence is:
> * hotrod -> node1
> * node1 -> node2, node4
> * node2 committed entry
> * node4 performed clustered get before write, got a value from node2 and will not commit the entry because this node thinks it's not changed/created
> * node1 committed entry
> * node2 invalidates the entry because it's no longer an owner
> Result owners(7c29bccb) are only node1 and node4 is missing. This entry may be completely lost by further rebalances when node4 is donor for this segment.
--
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, 7 months
[JBoss JIRA] (ISPN-3389) Forwarded transactions can remain stale after state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3389?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3389:
------------------------------------
Erik, I looked at the log and I didn't find transaction GlobalTransaction:<west-dht1-8815(CH2-Chicago-IL)>:58590:local at all, are you sure this is the right log file?
> Forwarded transactions can remain stale after state transfer
> ------------------------------------------------------------
>
> Key: ISPN-3389
> URL: https://issues.jboss.org/browse/ISPN-3389
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 5.2.x
> Fix For: 6.0.0.CR1, 6.0.0.Final
>
>
> There is a scenario where a tx started on one node, moved during state transfer, and committed on the originating node won't be removed from the new owner's tx table.
> The chain of events is as follows:
> 1. New topology comes in as part of a view change.
> 2. Local transaction started with the new topology ID. This transaction was started due to a LockControlCommand and has no modifications. Also important, it only has local locks.
> 3. Tx forwarded to new owner before the local lock is acquired and registered with the transaction.
> 4. Since the tx has only local locks and no modifications, it is only removed locally. No TxCompletion or Rollback are broadcast to the new owners.
> This key becomes unusable not due to stale locks, but because the waitForTransaction() code will see that the old tx can "potentially" lock the key.
> This easily happens with pessimistic caches, though I have seen it happen with optimistic caches (there is a delta between the transaction being created and the lock registration).
--
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, 7 months
[JBoss JIRA] (ISPN-3428) SpyMemcachedCompatibleMarshaller does not work in clustered mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3428?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3428:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=999954
> SpyMemcachedCompatibleMarshaller does not work in clustered mode
> ----------------------------------------------------------------
>
> Key: ISPN-3428
> URL: https://issues.jboss.org/browse/ISPN-3428
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Alpha2
> Reporter: Martin Gencur
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: DistCustomMemcachedEmbeddedTest.java
>
>
> I'm getting the following exception when using two-node cluster and storing data (String data) to one of the nodes with SpyMemcached. ClassCastException is thrown.
> {code}
> 2013-08-21 13:06:31,593 DEBUG (MemcachedServerWorker-17) [org.infinispan.server.memcached.MemcachedDecoder] Exception caught
> org.infinispan.server.memcached.MemcachedException: SERVER_ERROR org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistMemcachedEmbeddedTest-NodeA-30229, see cause for remote stack trace
> at org.infinispan.server.memcached.MemcachedDecoder.createServerException(MemcachedDecoder.scala:468)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:57)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:27)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:372)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107)
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistMemcachedEmbeddedTest-NodeA-30229, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:38)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:508)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:288)
> at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:148)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:278)
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:330)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:143)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:45)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.invokeNextWithRetry(StateTransferInterceptor.java:209)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:192)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:170)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:112)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitPutKeyValueCommand(TypeConverterInterceptor.java:73)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:867)
> at org.infinispan.CacheImpl.put(CacheImpl.java:859)
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:470)
> at org.infinispan.server.core.AbstractProtocolDecoder.put(AbstractProtocolDecoder.scala:181)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeValue(AbstractProtocolDecoder.scala:138)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:53)
> ... 14 more
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to [B
> at org.infinispan.server.memcached.MemcachedTypeConverter.boxValue(MemcachedTypeConverter.scala:14)
> at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitPutKeyValueCommand(TypeConverterInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:46)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:169)
> ... 3 more
> 2013-08-21 13:06:31,598 ERROR (testng-DistMemcachedEmbeddedTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Test testMemcachedPutEmbeddedGet(org.infinispan.it.compatibility.DistMemcachedEmbeddedTest) failed.
> java.util.concurrent.ExecutionException: OperationException: SERVER: SERVER_ERROR org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistMemcachedEmbeddedTest-NodeA-30229, see cause for remote stack trace
> at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:72)
> at org.infinispan.it.compatibility.DistMemcachedEmbeddedTest.testMemcachedPutEmbeddedGet(DistMemcachedEmbeddedTest.java:40)
> 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:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: OperationException: SERVER: SERVER_ERROR org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistMemcachedEmbeddedTest-NodeA-30229, see cause for remote stack trace
> at net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:123)
> at net.spy.memcached.protocol.ascii.OperationImpl.readFromBuffer(OperationImpl.java:130)
> at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:401)
> at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:333)
> at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:219)
> at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1591)
> {code}
> The test to reproduce this issue is here: https://github.com/mgencur/infinispan/commit/2e678e2c0ee0070be1a610cb7fb2...
--
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, 7 months
[JBoss JIRA] (ISPN-3430) Different CacheEntryEvents fired in library mode and compatibility mode
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-3430:
------------------------------
Description:
According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
on replace() method: CacheEntryModifiedEvent
But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this:
on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent
I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test
The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes.
Summary,
In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test.
Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
This is the +1/-1 thing I was talking about.
The difference in replace() method between library and compatibility mode remains.
Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.
was:
According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
on replace() method: CacheEntryModifiedEvent
// EDIT: NOT TRUE, DON'T READ --- on remove() method: CacheEntryRemovedEvent, CacheEntryModifiedEvent ---
But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this:
on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent
// EDIT: THIS IS OK --- on remove() method: CacheEntryRemovedEvent ---
EDIT:
I further explored the test CustomClassLoaderListenerTest and found new bug + bug in the test
The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes.
Summary,
In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test.
Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
This is the +1/-1 thing I was talking about.
The difference in replace() method between library and compatibility mode remains.
Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.
> Different CacheEntryEvents fired in library mode and compatibility mode
> -----------------------------------------------------------------------
>
> Key: ISPN-3430
> URL: https://issues.jboss.org/browse/ISPN-3430
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote protocols
> Affects Versions: 6.0.0.Alpha2
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
>
> According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode:
> on replace() method: CacheEntryModifiedEvent
> But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this:
> on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent
> I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test
> The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes.
> Summary,
> In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test.
> Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent.
> This is the +1/-1 thing I was talking about.
> The difference in replace() method between library and compatibility mode remains.
> Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug.
--
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, 7 months
[JBoss JIRA] (ISPN-3029) IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3029?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3029:
------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2018
> IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
> -----------------------------------------------------------------
>
> Key: ISPN-3029
> URL: https://issues.jboss.org/browse/ISPN-3029
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.5.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: onboard
> Fix For: 6.0.0.Final
>
>
> Most LockSupportCacheStore methods that call {{acquireGlobalLock()}} ignore its return value and proceed as if the lock was acquired on all the buckets. ISPN-2378 partially fixed this by only attempting to unlock the global lock if the lock was actually acquired, but the processing that was supposed to be protected by the global lock is still executed even if the lock acquisition failed.
> In {{loadAllKeys}}, this doesn't usually cause any problems. But if the cache store contains expired entries, it will try to upgrade a bucket lock to a write lock in order to update the bucket on disk, and the upgrade will fail with a IllegalMonitorStateException:
> {noformat}
> > 20:41:36,960 ERROR [org.infinispan.statetransfer.OutboundTransferTask] (undefined) Failed to execute outbound transfer: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
> > at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883) [rt.jar:1.7.0_09-icedtea]
> > at org.infinispan.util.concurrent.locks.StripedLock.upgradeLock(StripedLock.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.LockSupportCacheStore.upgradeLock(LockSupportCacheStore.java:106) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore.access$000(BucketBasedCacheStore.java:49) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore$CollectionGeneratingBucketHandler.handle(BucketBasedCacheStore.java:159) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.file.FileCacheStore.loopOverBuckets(FileCacheStore.java:102) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore.loadAllKeysLockSafe(BucketBasedCacheStore.java:219) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.LockSupportCacheStore.loadAllKeys(LockSupportCacheStore.java:179) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AbstractDelegatingStore.loadAllKeys(AbstractDelegatingStore.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AsyncStore.loadKeys(AsyncStore.java:184) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AsyncStore.loadAllKeys(AsyncStore.java:205) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:163) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-2.jar:2.0.0.GA-redhat-2]
> {noformat}
> A simple solution would be to throw an exception any time the global lock acquisition failed, but the current global lock acquisition algorithm might need to change because it seems very deadlock-prone at the moment.
--
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, 7 months
[JBoss JIRA] (ISPN-3029) IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3029?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3029:
------------------------------
Fix Version/s: 6.0.0.Alpha3
> IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
> -----------------------------------------------------------------
>
> Key: ISPN-3029
> URL: https://issues.jboss.org/browse/ISPN-3029
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.5.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: onboard
> Fix For: 6.0.0.Alpha3, 6.0.0.Final
>
>
> Most LockSupportCacheStore methods that call {{acquireGlobalLock()}} ignore its return value and proceed as if the lock was acquired on all the buckets. ISPN-2378 partially fixed this by only attempting to unlock the global lock if the lock was actually acquired, but the processing that was supposed to be protected by the global lock is still executed even if the lock acquisition failed.
> In {{loadAllKeys}}, this doesn't usually cause any problems. But if the cache store contains expired entries, it will try to upgrade a bucket lock to a write lock in order to update the bucket on disk, and the upgrade will fail with a IllegalMonitorStateException:
> {noformat}
> > 20:41:36,960 ERROR [org.infinispan.statetransfer.OutboundTransferTask] (undefined) Failed to execute outbound transfer: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
> > at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883) [rt.jar:1.7.0_09-icedtea]
> > at org.infinispan.util.concurrent.locks.StripedLock.upgradeLock(StripedLock.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.LockSupportCacheStore.upgradeLock(LockSupportCacheStore.java:106) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore.access$000(BucketBasedCacheStore.java:49) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore$CollectionGeneratingBucketHandler.handle(BucketBasedCacheStore.java:159) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.file.FileCacheStore.loopOverBuckets(FileCacheStore.java:102) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.bucket.BucketBasedCacheStore.loadAllKeysLockSafe(BucketBasedCacheStore.java:219) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.LockSupportCacheStore.loadAllKeys(LockSupportCacheStore.java:179) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AbstractDelegatingStore.loadAllKeys(AbstractDelegatingStore.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AsyncStore.loadKeys(AsyncStore.java:184) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.loaders.decorators.AsyncStore.loadAllKeys(AsyncStore.java:205) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:163) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-2.jar:2.0.0.GA-redhat-2]
> {noformat}
> A simple solution would be to throw an exception any time the global lock acquisition failed, but the current global lock acquisition algorithm might need to change because it seems very deadlock-prone at the moment.
--
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, 7 months
[JBoss JIRA] (ISPN-2013) Using explicit "unlock" causes TimeoutException for other Threads
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2013:
------------------------------
Fix Version/s: 6.0.0.Alpha3
> 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: Pedro Ruivo
> Fix For: 6.0.0.Alpha3, 6.0.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
12 years, 7 months
[JBoss JIRA] (ISPN-2013) Using explicit "unlock" causes TimeoutException for other Threads
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2013 started by Pedro Ruivo.
> 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: Pedro Ruivo
> Fix For: 6.0.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
12 years, 7 months