[JBoss JIRA] (ISPN-7011) @AfterClass cleanup doesn't work with @InTransactionMode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7011?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7011:
----------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.0.0.Final)
> @AfterClass cleanup doesn't work with @InTransactionMode
> --------------------------------------------------------
>
> Key: ISPN-7011
> URL: https://issues.jboss.org/browse/ISPN-7011
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 9.1.0.Final
>
>
> Very much like ISPN-7003, TestNG's {{TestMethodWorker.invokeAfterClassMethods}} never sees an empty list of methods in {{m_classMethodMap}}. That happens because {{m_classMethodMap}} is populated before our {{ChainMethodInterceptor}} had a chance to filter the methods (e.g. when a test method has an {{@InTransactionMode}} annotation).
> Normally this is not a problem because each test has a different name, and the test suite tolerates some leaked managers. But when you run a test like {{PutForExternalReadTest}} with {{-Dtest.infinispan.shortTestName=true}}, you get this failure:
> {noformat}
> java.lang.IllegalStateException: Two tests with the same name running in parallel: test
> at org.infinispan.test.fwk.TestResourceTracker.testStarted(TestResourceTracker.java:88)
> at org.infinispan.test.AbstractInfinispanTest.testClassStarted(AbstractInfinispanTest.java:115)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
> at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7008) IllegalLifeCycleStateException from BlockingRunnable.isReady() escapes to originator
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7008?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7008:
----------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.0.0.Final)
> IllegalLifeCycleStateException from BlockingRunnable.isReady() escapes to originator
> ------------------------------------------------------------------------------------
>
> Key: ISPN-7008
> URL: https://issues.jboss.org/browse/ISPN-7008
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.4.Final, 9.0.0.Alpha4
> Reporter: Dan Berindei
> Fix For: 9.1.0.Final
>
>
> The ISPN-5539 fix caught {{IllegalLifecycleStateException}} in {{BlockingRunnable.run()}} and sent a {{CacheNotFoundResponse}} to the originator instead. However, exceptions thrown from {{BlockingRunnable.isReady()}} are not caught, and are instead sent back to the originator. An example stack trace is available in the WFLY-7029 description.
> In this case, the exception was thrown directly when the inbound invocation handler tried to submit the command to the remote commands executor. But I see a related problem in {{BlockingTaskAwareExecutorServiceImpl.ControllerThread.run()}}, which stops with the first exception from {{isReady()}}. For {{IllegalLifecycleStateException}} it's probably ok, but for other exceptions it should continue processing new tasks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7026) CacheClusterJoinTest.testIsCoordinator random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7026?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7026:
----------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.0.0.Final)
> CacheClusterJoinTest.testIsCoordinator random failures
> ------------------------------------------------------
>
> Key: ISPN-7026
> URL: https://issues.jboss.org/browse/ISPN-7026
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Final
>
>
> {{CacheClusterJoinTest.testIsCoordinator}} assumes that once {{JGroupsTransport}} received a view, {{JGroupsTransport.isCoordinator()}} returns the correct value.
> However, only {{JGroupsTransfer.viewAccepted}} is synchronized, {{isCoordinator()}} is not, so the main thread can see {{isCoordinator() == false}} even after {{getMembers().get(0) == self}}.
> {noformat}
> 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] New view accepted: [Test-NodeD-36891|2] (1) [Test-NodeD-36891]
> 19:32:27,556 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.api.CacheClusterJoinTest.testIsCoordinator
> java.lang.AssertionError
> at org.infinispan.api.CacheClusterJoinTest.testIsCoordinator(CacheClusterJoinTest.java:65) ~[test-classes/:?]
> 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] Joined: [], Left: [Test-NodeC-35712]
> {noformat}
> It would be nice if {{isCoordinator()}}, {{getCoordinator()}}, and {{getMembers()}} were more in sync, even though the view can always change between two calls. The simplest way to do this would be to implement {{isCoordinator()}} and {{getCoordinator()}} on top of {{getMembers()}} and remove their fields, since they're not use in performance-sensitive code.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-6971) Use JChannel directly instead of going through MessageDispatcher
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6971?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6971:
----------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.0.0.Final)
> Use JChannel directly instead of going through MessageDispatcher
> ----------------------------------------------------------------
>
> Key: ISPN-6971
> URL: https://issues.jboss.org/browse/ISPN-6971
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 9.1.0.Final
>
>
> JGroups changed its serialization in 4.0, and even when using MessageDispatcher we still have to provide a JGroups-style marshaller for deserializing RPC responses. If we used JChannel directly, we could avoid this, and we'd have more control over how we process responses.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-6997) PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6997?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6997:
----------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.0.0.Final)
> PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-6997
> URL: https://issues.jboss.org/browse/ISPN-6997
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Final
>
>
> The test starts with a cluster of 4 nodes, and splits it in 2 partitions while a transaction is trying to lock a key. After the transaction fails, it checks that the transaction has been cleaned up properly.
> On one of the owners, {{transactionTable.cleanupLeaverTransactions}} is being called only before the split and after the merge, never with the list of members during the split. That means it never sees the transaction as an orphan, and doesn't remove it.
> {noformat}
> 15:16:18,893 TRACE (testng-PTPAMDRT:[]) [PTPAMDRT] Local tx=[], remote tx=[GlobalTx:PTPAMDRT-NodeI-3337:28616], for cache PTPAMDRT-NodeJ-27814
> 15:16:18,893 ERROR (testng-PTPAMDRT:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PTPAMDRT.testOriginatorIsolatedPartition
> java.lang.AssertionError: There are pending transactions!
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:223) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:519) ~[test-classes/:?]
> at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:794) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:96) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:82) ~[test-classes/:?]
> at org.infinispan.partitionhandling.tionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition(PessimisticTxPartitionAndMergeDuringRuntimeTest.java:33) ~[test-classes/:?]
> {noformat}
> {{OptimisticTxPartitionAndMergeDuringCommitTest.testPrimaryOwnerIsolatedPartition}} has similar random failures.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7672) NonTotalOrderTxPerCacheInboundInvocationHandler throws warning when adding cache entry using Spring Session
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7672?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7672:
----------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.0.0.Final)
> NonTotalOrderTxPerCacheInboundInvocationHandler throws warning when adding cache entry using Spring Session
> -----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-7672
> URL: https://issues.jboss.org/browse/ISPN-7672
> Project: Infinispan
> Issue Type: Bug
> Components: Cloud Integrations, Spring Integration
> Affects Versions: 9.0.0.CR4
> Reporter: Sebastian Łaskawiec
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 9.1.0.Final
>
>
> When I'm trying to add an entry using Spring Session integration with a [transactional cache|https://github.com/slaskawi/presentations/blob/master/2017_spring_s...], the server throws a warning:
> {code}
> [transactions-repository-1-2cbrv] 06:53:40,773 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (remote-thread--p2-t18) ISPN000071: Caught exception when handling command DistributedExecuteCommand [cache=Cache 'sessions'@transactions-repository-1-2cbrv, keys=[], callable=ClusterEventCallable{identifier=b345211e-fbd7-4305-b3a6-6979301e0360, events=[ClusterEvent {type=CACHE_ENTRY_CREATED, cache=Cache 'sessions'@transactions-repository-1-2cbrv, key=[B@8c75820, value=[B@76856353, oldValue=null, transaction=RecoveryAwareGlobalTransaction{xid=< 131077, 29, 36, 0000000000-1-1-84170374-96-629488-44-62370001349, 0000000000-1-1-84170374-96-629488-44-62370001400000000 >, internalId=562954248388609} GlobalTx:transactions-repository-1-cwk6f:1, retryCommand=false, origin=transactions-repository-1-cwk6f}]}]: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.ClassCastException] while invoking method [public void org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(org.infinispan.notifications.cachelistener.event.CacheEntryEvent)] on listener instance: org.infinispan.server.hotrod.ClientListenerRegistry$StatelessClientEventSender@7b97a57
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:401)
> [transactions-repository-1-2cbrv] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:20)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:419)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1512)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1508)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1503)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyClusterListeners(CacheNotifierImpl.java:711)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.cluster.ClusterEventCallable.call(ClusterEventCallable.java:49)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.cachelistener.cluster.ClusterEventCallable.call(ClusterEventCallable.java:25)
> [transactions-repository-1-2cbrv] at org.infinispan.commands.read.DistributedExecuteCommand.invokeAsync(DistributedExecuteCommand.java:99)
> [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:90)
> [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:90)
> [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:68)
> [transactions-repository-1-2cbrv] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> [transactions-repository-1-2cbrv] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [transactions-repository-1-2cbrv] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [transactions-repository-1-2cbrv] at java.lang.Thread.run(Thread.java:745)
> [transactions-repository-1-2cbrv] Caused by: java.lang.ClassCastException: org.infinispan.container.versioning.SimpleClusteredVersion cannot be cast to org.infinispan.container.versioning.NumericVersion
> [transactions-repository-1-2cbrv] at org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(ClientListenerRegistry.java:363)
> [transactions-repository-1-2cbrv] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [transactions-repository-1-2cbrv] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [transactions-repository-1-2cbrv] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [transactions-repository-1-2cbrv] at java.lang.reflect.Method.invoke(Method.java:498)
> [transactions-repository-1-2cbrv] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:396)
> [transactions-repository-1-2cbrv] ... 16 more
> [transactions-repository-1-2cbrv]
> {code}
> This didn't happen in {{CR2}} release, so there must be something that changed since then. I also noticed that this sometimes leads to exceptions in the Hot Rod client.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7606) DistributedExecutorMassIndexer.executeInternal should use an existing pool
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7606?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7606:
----------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.0.0.Final)
> DistributedExecutorMassIndexer.executeInternal should use an existing pool
> --------------------------------------------------------------------------
>
> Key: ISPN-7606
> URL: https://issues.jboss.org/browse/ISPN-7606
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
> Fix For: 9.1.0.Final
>
>
> {{DistributedExecutorMassIndexer.executeInternal}} creates 2 executors:
> 1. {{new DefaultExecutorService(cache)}} implicitly creates a single-threaded executor to run tasks on the local node.
> 2. {{compositeFuture.whenCompleteAsync(consumer, Executors.newSingleThreadExecutor())}} explicitly creates a new single-threaded executor to run the consumer on.
> Neither of these executors are shut down, and rather than complicating the code to stop them properly it would be better to use an existing executor.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years