[JBoss JIRA] (ISPN-3338) DistributionManager operations Locate key & Is key local are not working properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3338?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3338:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=986341
> DistributionManager operations Locate key & Is key local are not working properly
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3338
> URL: https://issues.jboss.org/browse/ISPN-3338
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Environment: Tested localy Fedora16
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
>
> Testing infinispan-rhq-plugin (for InVM).
> DistributionManager operations Locate key & Is key local seem not to working properly. For a nonsense key Locate key operation is returning success with result of a label for cache "home node".
> Is key local operation for nonsense key is returning TRUE which is obviously wrong. This happens even on totally clear, entry-free, cache.
> Operation Could key be affected by a rehash is returning operation success with result false. This is questionable whether it should return failure or not. Again, for nonsense key.
> Please can anyone look at it?
> I don't think this is directly jon/plugin related.
--
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-3339) Jon plugin, two deprecated ops are failing. [RpcManager] [Transaction]
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3339?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3339:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=986342
> Jon plugin, two deprecated ops are failing. [RpcManager] [Transaction]
> ----------------------------------------------------------------------
>
> Key: ISPN-3339
> URL: https://issues.jboss.org/browse/ISPN-3339
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Environment: Local machine, Fedora16
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
>
> These 2 operations are failing using infinispan-rhq-plugin:
> [Transactions] Enable/disable statistics. Deprecated, use the statisticsEnabled attribute instead.
> [RpcManager] Enable/disable statistics. Deprecated, use the statisticsEnabled attribute instead.
> While this is deprecated, should we remove it from plugin? Should we replace it by different operation?
> Typical error stack trace:
> org.mc4j.ems.connection.EmsInvocationException: Exception on invocation of [setStatisticsEnabled]javax.management.MBeanException
> at org.mc4j.ems.impl.jmx.connection.bean.operation.DOperation.invoke(DOperation.java:126)
> at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:192)
> at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634)
> 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:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: javax.management.MBeanException
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
> at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
> at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
> at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160)
> at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source)
> at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:1017)
> at sun.reflect.GeneratedMethodAccessor131.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.mc4j.ems.impl.jmx.connection.support.providers.proxy.JMXRemotingMBeanServerProxy.invoke(JMXRemotingMBeanServerProxy.java:59)
> at $Proxy110.invoke(Unknown Source)
> at org.mc4j.ems.impl.jmx.connection.bean.operation.DOperation.invoke(DOperation.java:110)
> ... 10 more
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:269)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
> at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
> at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
> at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
--
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-3434) DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3434?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3434:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled
> --------------------------------------------------------------
>
> Key: ISPN-3434
> URL: https://issues.jboss.org/browse/ISPN-3434
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Reporter: William Burns
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Beta1
>
>
> The decorate method doesn't invoke the super method, which causes the L1 to not be enabled. By invoking the super method and enabling L1, there are actually failing tests.
> Failed tests:
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKey:73->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeAY-38834. expected:<v1> but was:<v2>
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKeyOnNonOwner:77->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBC-51791. expected:<v1> but was:<v2>
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKey:65->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBF-6894. expected:<v1> but was:<v2>
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKeyOnNonOwner:69->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBK-23011. expected:<v1> but was:<v2>
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKey:89->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBO-8015. expected:<null> but was:<v2>
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKeyOnNonOwner:93->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBS-18673. expected:<null> but was:<v2>
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKey:81->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBV-26641. expected:<null> but was:<v2>
> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKeyOnNonOwner:85->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeCA-47053. expected:<null> but was:<v2>
> DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testNullEntries:185 null
> DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkew:48 null
> DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkewMultiEntries:146 null
--
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-2913) putForExternalRead leaves locks
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2913?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2913:
------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1737, https://github.com/infinispan/infinispan/pull/2031 (was: https://github.com/infinispan/infinispan/pull/1737)
> putForExternalRead leaves locks
> -------------------------------
>
> Key: ISPN-2913
> URL: https://issues.jboss.org/browse/ISPN-2913
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Final
>
> Attachments: SebastianTusk_ISPN-2913.patch
>
>
> In TxDistributionInterceptor.remoteGetAndStoreInL1 locks are acquired. Without a transaction these locks are never released. The cache setup is Dist, Async, L1, 2 Nodes, 1 Owner, Optimistic Locking.
> In AbstractTxLockingInterceptor.visitGetKeyValueCommand locks are released explicitly if outside of transactions. I fixed this problem by doing the same in OptimisticLockingInterceptor.visitPutKeyValueCommand. It is very likely that this doesn't fix all problems. For instance OptimisticLockingInterceptor.visitPutMapCommand or PessimisticLockingInterceptor.
> Cache Config:
> <namedCache name="entity">
> <jmxStatistics enabled="true" />
>
> <clustering mode="dist">
> <stateTransfer fetchInMemoryState="false" timeout="20000" />
> <async />
> <l1 enabled="true" />
> <hash numOwners="1"/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED"
> lockAcquisitionTimeout="15000" useLockStriping="false" />
>
> <eviction maxEntries="10000" strategy="LRU" />
> <expiration maxIdle="100000" wakeUpInterval="5000"/>
> <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
>
> <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
> </namedCache>
> Fixed OptimisticLockingInterceptor.visitPutKeyValueCommand:
> @Override
> public Object visitPutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable {
> try {
> if (command.isConditional()) markKeyAsRead(ctx, command);
> return invokeNextInterceptor(ctx, command);
> } catch (Throwable te) {
> throw cleanLocksAndRethrow(ctx, te);
> } finally {
> //with putForExternalRead the value might be put into L1 without a transaction
> //we need to release any locks for these cases
> if (!ctx.isInTxScope()) lockManager.unlockAll(ctx);
> }
> }
--
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-2913) putForExternalRead leaves locks
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2913?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2913:
------------------------------
Fix Version/s: 6.0.0.Beta1
> putForExternalRead leaves locks
> -------------------------------
>
> Key: ISPN-2913
> URL: https://issues.jboss.org/browse/ISPN-2913
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
> Attachments: SebastianTusk_ISPN-2913.patch
>
>
> In TxDistributionInterceptor.remoteGetAndStoreInL1 locks are acquired. Without a transaction these locks are never released. The cache setup is Dist, Async, L1, 2 Nodes, 1 Owner, Optimistic Locking.
> In AbstractTxLockingInterceptor.visitGetKeyValueCommand locks are released explicitly if outside of transactions. I fixed this problem by doing the same in OptimisticLockingInterceptor.visitPutKeyValueCommand. It is very likely that this doesn't fix all problems. For instance OptimisticLockingInterceptor.visitPutMapCommand or PessimisticLockingInterceptor.
> Cache Config:
> <namedCache name="entity">
> <jmxStatistics enabled="true" />
>
> <clustering mode="dist">
> <stateTransfer fetchInMemoryState="false" timeout="20000" />
> <async />
> <l1 enabled="true" />
> <hash numOwners="1"/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED"
> lockAcquisitionTimeout="15000" useLockStriping="false" />
>
> <eviction maxEntries="10000" strategy="LRU" />
> <expiration maxIdle="100000" wakeUpInterval="5000"/>
> <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
>
> <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
> </namedCache>
> Fixed OptimisticLockingInterceptor.visitPutKeyValueCommand:
> @Override
> public Object visitPutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable {
> try {
> if (command.isConditional()) markKeyAsRead(ctx, command);
> return invokeNextInterceptor(ctx, command);
> } catch (Throwable te) {
> throw cleanLocksAndRethrow(ctx, te);
> } finally {
> //with putForExternalRead the value might be put into L1 without a transaction
> //we need to release any locks for these cases
> if (!ctx.isInTxScope()) lockManager.unlockAll(ctx);
> }
> }
--
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-2913) putForExternalRead leaves locks
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2913?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2913 started by Pedro Ruivo.
> putForExternalRead leaves locks
> -------------------------------
>
> Key: ISPN-2913
> URL: https://issues.jboss.org/browse/ISPN-2913
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Final
>
> Attachments: SebastianTusk_ISPN-2913.patch
>
>
> In TxDistributionInterceptor.remoteGetAndStoreInL1 locks are acquired. Without a transaction these locks are never released. The cache setup is Dist, Async, L1, 2 Nodes, 1 Owner, Optimistic Locking.
> In AbstractTxLockingInterceptor.visitGetKeyValueCommand locks are released explicitly if outside of transactions. I fixed this problem by doing the same in OptimisticLockingInterceptor.visitPutKeyValueCommand. It is very likely that this doesn't fix all problems. For instance OptimisticLockingInterceptor.visitPutMapCommand or PessimisticLockingInterceptor.
> Cache Config:
> <namedCache name="entity">
> <jmxStatistics enabled="true" />
>
> <clustering mode="dist">
> <stateTransfer fetchInMemoryState="false" timeout="20000" />
> <async />
> <l1 enabled="true" />
> <hash numOwners="1"/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED"
> lockAcquisitionTimeout="15000" useLockStriping="false" />
>
> <eviction maxEntries="10000" strategy="LRU" />
> <expiration maxIdle="100000" wakeUpInterval="5000"/>
> <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
>
> <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
> </namedCache>
> Fixed OptimisticLockingInterceptor.visitPutKeyValueCommand:
> @Override
> public Object visitPutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable {
> try {
> if (command.isConditional()) markKeyAsRead(ctx, command);
> return invokeNextInterceptor(ctx, command);
> } catch (Throwable te) {
> throw cleanLocksAndRethrow(ctx, te);
> } finally {
> //with putForExternalRead the value might be put into L1 without a transaction
> //we need to release any locks for these cases
> if (!ctx.isInTxScope()) lockManager.unlockAll(ctx);
> }
> }
--
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