[JBoss JIRA] (ISPN-3800) Multiple ExecutorAllCompletionServices using the same executor may interfere
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3800?page=com.atlassian.jira.plugin.... ]
Radim Vansa resolved ISPN-3800.
-------------------------------
Resolution: Rejected
My mistake, only the executor is shared, the executor service having the queue inside is private to the ExecutorAllCompletionService.
> Multiple ExecutorAllCompletionServices using the same executor may interfere
> ----------------------------------------------------------------------------
>
> Key: ISPN-3800
> URL: https://issues.jboss.org/browse/ISPN-3800
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If there are multiple ExecutorAllCompletionServices using the same executor, these may steal other's futures, and therefore, report the task to be finished prematurely.
> This may be the case for a preload from multiple cache loaders in parallel.
> The tasks sent to the executor have to be tagged and the service should poll only its own tasks.
--
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, 1 month
[JBoss JIRA] (ISPN-3800) Multiple ExecutorAllCompletionServices using the same executor may interfere
by Radim Vansa (JIRA)
Radim Vansa created ISPN-3800:
---------------------------------
Summary: Multiple ExecutorAllCompletionServices using the same executor may interfere
Key: ISPN-3800
URL: https://issues.jboss.org/browse/ISPN-3800
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.0.Final
Reporter: Radim Vansa
Assignee: Radim Vansa
If there are multiple ExecutorAllCompletionServices using the same executor, these may steal other's futures, and therefore, report the task to be finished prematurely.
This may be the case for a preload from multiple cache loaders in parallel.
The tasks sent to the executor have to be tagged and the service should poll only its own tasks.
--
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, 1 month
[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 updated ISPN-3422:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2254
> 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: 620, nbst
> Fix For: 6.1.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
12 years, 1 month
[JBoss JIRA] (ISPN-3652) Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3652?page=com.atlassian.jira.plugin.... ]
Jiří Holuša commented on ISPN-3652:
-----------------------------------
The following tests hanged on Windows 2012 JDK6:
org.infinispan.statetransfer.StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusy
These tests hanged on Windows 2008 JDK6:
org.infinispan.statetransfer.ClusterTopologyManagerTest.testClusterRecoveryWithRebalance
org.infinispan.statetransfer.StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusy
Stacktrace:
org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
at org.infinispan.CacheImpl.start(CacheImpl.java:666)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:551)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:514)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:396)
at org.infinispan.statetransfer.StateTransferReplicationQueueTest.thirdWritingCacheTest(StateTransferReplicationQueueTest.java:101)
at org.infinispan.statetransfer.StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusy(StateTransferReplicationQueueTest.java:81)
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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
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:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.infinispan.util.concurrent.TimeoutException: Node StateTransferReplicationQueueTest-NodeA-25090 timed out
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:174)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:287)
at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:100)
at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:97)
at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 32 more
Caused by: org.jgroups.TimeoutException: TimeoutException
at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145)
at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40)
at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93)
at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:321)
at org.jgroups.protocols.RSVP.down(RSVP.java:117)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
at org.jgroups.JChannel.down(JChannel.java:760)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:683)
at org.jgroups.blocks.RequestCorrelator.sendUnicastRequest(RequestCorrelator.java:202)
at org.jgroups.blocks.UnicastRequest.sendRequest(UnicastRequest.java:43)
at org.jgroups.blocks.Request.execute(Request.java:83)
at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:399)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:353)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
... 40 more
> Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6
> -----------------------------------------------------------------------------------
>
> Key: ISPN-3652
> URL: https://issues.jboss.org/browse/ISPN-3652
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Environment: Windows 2012 && JDK6
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: testsuite_stability
>
> The tests for the environment specified hang randomly on package org.infinispan.statetransfer.
> Due to not being able to login to executing machine at the moment I cannot provide logs/thread dump for the hanged tests.
> The logs would be attached later.
--
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, 1 month
[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ]
William Burns resolved ISPN-3422.
---------------------------------
Resolution: Done
> 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: 620, nbst
> Fix For: 6.1.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
12 years, 1 month
[JBoss JIRA] (ISPN-3777) ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3777?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3777:
------------------------------------
If the operation is asynchronous, then the thread local is definitely not needed in the caller thread... let's try to remove it completely and see what happens.
> ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
> --------------------------------------------------------------------------------------------------
>
> Key: ISPN-3777
> URL: https://issues.jboss.org/browse/ISPN-3777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Marko Lukša
> Assignee: Marko Lukša
> Priority: Critical
>
> When running CapeDwarf log tests on Infinispan 6.0.0 & Wildfly, we're seeing lots of retained instances of LocalTxInvocationContext.
> So far I've seen the instances that are not removed are created at the following two points:
> {code}
> java.lang.Exception: Creation stack
> at org.infinispan.context.impl.LocalTxInvocationContext.<init>(LocalTxInvocationContext.java:42)
> at org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(TransactionalInvocationContextContainer.java:100)
> at org.infinispan.CacheImpl.getInvocationContext(CacheImpl.java:615)
> at org.infinispan.CacheImpl.getInvocationContextWithImplicitTransaction(CacheImpl.java:599)
> at org.infinispan.CacheImpl.getInvocationContextWithImplicitTransactionForAsyncOps(CacheImpl.java:569)
> at org.infinispan.CacheImpl.putAsync(CacheImpl.java:996)
> at org.infinispan.DecoratedCache.putAsync(DecoratedCache.java:238)
> at org.infinispan.AbstractDelegatingCache.putAsync(AbstractDelegatingCache.java:131)
> at org.jboss.capedwarf.log.CapedwarfLogService$AsyncLogWriter.put(CapedwarfLogService.java:378)
> at org.jboss.capedwarf.log.CapedwarfLogService.requestFinished(CapedwarfLogService.java:348)
> at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:47)
> at org.jboss.capedwarf.aspects.DisableSocketsAspect.invoke(DisableSocketsAspect.java:43)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.GlobalTimeLimitAspect.invoke(GlobalTimeLimitAspect.java:44)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.proxy.AspectHandler.invoke(AspectHandler.java:60)
> at org.jboss.capedwarf.log.ExposedLogService_$$_jvst183_0.requestFinished(ExposedLogService_$$_jvst183_0.java)
> at org.jboss.capedwarf.appidentity.GAEListener.requestDestroyed(GAEListener.java:125)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:638)
> 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:744)
> {code}
> and
> {code}
> java.lang.Exception: Creation stack
> at org.infinispan.context.impl.LocalTxInvocationContext.<init>(LocalTxInvocationContext.java:42)
> at org.infinispan.context.TransactionalInvocationContextContainer.createTxInvocationContext(TransactionalInvocationContextContainer.java:110)
> at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:145)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:532)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
> at org.infinispan.CacheImpl.put(CacheImpl.java:861)
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> at org.jboss.capedwarf.log.CapedwarfLogService$SyncLogWriter.put(CapedwarfLogService.java:390)
> at org.jboss.capedwarf.log.CapedwarfLogService.requestFinished(CapedwarfLogService.java:348)
> at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:47)
> at org.jboss.capedwarf.aspects.DisableSocketsAspect.invoke(DisableSocketsAspect.java:43)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.GlobalTimeLimitAspect.invoke(GlobalTimeLimitAspect.java:44)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.proxy.AspectHandler.invoke(AspectHandler.java:60)
> at org.jboss.capedwarf.log.ExposedLogService_$$_jvst8b1_0.requestFinished(ExposedLogService_$$_jvst8b1_0.java)
> at org.jboss.capedwarf.appidentity.GAEListener.requestDestroyed(GAEListener.java:125)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:638)
> 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:744)
> {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
12 years, 1 month