[JBoss JIRA] (ISPN-10981) CacheWriterTest.shouldWriteThoughUsingPutAll_partialSuccess random failures
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10981?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10981:
------------------------------------------
Sprint: DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #37, DataGrid Sprint #38)
> CacheWriterTest.shouldWriteThoughUsingPutAll_partialSuccess random failures
> ---------------------------------------------------------------------------
>
> Key: ISPN-10981
> URL: https://issues.redhat.com/browse/ISPN-10981
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 10.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.1.Final
>
>
> {{CacheWriterTest.shouldWriteThoughUsingPutAll_partialSuccess}} fails very often.
> {noformat}
> 17:34:36,699 ERROR [TestSuiteProgress] Test failed: CacheWriterTest.shouldWriteThroughRemoveAllSpecific_partialSuccess
> java.lang.AssertionError: expected:<Hola World> but was:<null>
> at org.junit.Assert.fail(Assert.java:88) ~[junit-4.12.jar:4.12]
> at org.junit.Assert.failNotEquals(Assert.java:834) ~[junit-4.12.jar:4.12]
> at org.junit.Assert.assertEquals(Assert.java:118) ~[junit-4.12.jar:4.12]
> at org.junit.Assert.assertEquals(Assert.java:144) ~[junit-4.12.jar:4.12]
> at org.jsr107.tck.integration.CacheWriterTest.shouldWriteThroughRemoveAllSpecific_partialSuccess(CacheWriterTest.java:1047) ~[cache-tests-1.1.0-tests.jar:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10937) CleanupAfterMethod tests take a very long time
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10937?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10937:
------------------------------------------
Sprint: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38)
> CleanupAfterMethod tests take a very long time
> ----------------------------------------------
>
> Key: ISPN-10937
> URL: https://issues.redhat.com/browse/ISPN-10937
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.0.Beta1
>
>
> Because of JGRP-2398, every time the cluster is stopped and re-created the new coordinator first tries to connect to the old coordinator:
> {noformat}
> 13:53:39,024 DEBUG (testng-Test:[]) [GMS] address=Test-NodeA-57106, cluster=org.infinispan.partitionhandling.Test, physical address=127.0.0.1:55320
> 13:53:39,026 TRACE (testng-Test:[]) [GMS] Test-NodeA-57106: discovery took 0 ms, members: 17 rsps (4 coords) [done]
> 13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, Test-NodeA-37104, Test-NodeA-8303]
> 13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca
> 13:53:41,026 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca timed out (after 2000 ms), on try 0
> ...
> 13:53:45,027 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
> 13:53:47,027 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 0
> ...
> 13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, 0eb381de-3e9a-0320-b2d9-5db3cb39bb34, Test-NodeA-8303]
> 13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3
> 13:54:53,036 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3 timed out (after 2000 ms), on try 9
> ...
> 13:54:57,037 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
> 13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 9
> 13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: too many JOIN attempts (10): becoming singleton
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10939) PessimisticTxPartitionAndMergeDuringRollbackTest random failures
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10939?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10939:
------------------------------------------
Sprint: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38)
> PessimisticTxPartitionAndMergeDuringRollbackTest random failures
> ----------------------------------------------------------------
>
> Key: ISPN-10939
> URL: https://issues.redhat.com/browse/ISPN-10939
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Attachments: test.log.gz
>
>
> {{PessimisticTxPartitionAndMergeDuringRollbackTest.testPrimaryOwnerIsolatedPartitionWithDiscard[DIST_SYNC, DENY_READ_WRITES]}} sometimes fails because {{NodeC}} never rolls back {{NodeA}}'s transaction. It's normal to not roll back the transaction on {{NodeC}} while it's in {{DEGRADED_MODE}}, but it should roll back the transaction after the merge.
> {noformat}
> 16:31:28,895 TRACE (ForkThread-1,PessimisticTxPartitionAndMergeDuringRollbackTest:[]) [TransactionCoordinator] rollback transaction GlobalTx:Test-NodeA-24422:22
> 16:31:28,897 DEBUG (jgroups-7,Test-NodeC-35037:[]) [BaseTxPartitionAndMergeTest] Ignoring command RollbackCommand {gtx=GlobalTx:Test-NodeA-24422:22, cacheName='pes-cache', topologyId=13}
> 16:31:28,898 DEBUG (testng-Test:[]) [GMS] Test-NodeC-35037: installing view [Test-NodeC-35037|31] (1) [Test-NodeC-35037]
> 16:31:28,904 DEBUG (testng-Test:[]) [GMS] Test-NodeA-24422: installing view [Test-NodeA-24422|32] (3) [Test-NodeA-24422, Test-NodeB-15428, Test-NodeD-40706]
> 16:31:28,968 TRACE (transport-thread-Test-NodeC-p181-t1:[Topology-pes-cache]) [TransactionTable] Checking for transactions originated on leavers. Current cache members are [Test-NodeC-35037], remote transactions: 1
> 16:31:28,971 TRACE (transport-thread-Test-NodeC-p181-t1:[Topology-pes-cache]) [TransactionTable] Checking transaction GlobalTx:Test-NodeA-24422:22
> 16:31:28,971 TRACE (transport-thread-Test-NodeC-p181-t1:[Topology-pes-cache]) [PartitionHandlingManagerImpl] Can rollback transaction? false
> 16:31:29,113 DEBUG (testng-Test:[]) [GMS] Test-NodeC-35037: installing view MergeView::[Test-NodeC-35037|35] (4) [Test-NodeC-35037, Test-NodeA-24422, Test-NodeB-15428, Test-NodeD-40706], 2 subgroups: [Test-NodeC-35037|33] (1) [Test-NodeC-35037], [Test-NodeA-24422|34] (3) [Test-NodeA-24422, Test-NodeB-15428, Test-NodeD-40706]
> 16:31:29,291 TRACE (transport-thread-Test-NodeC-p181-t4:[Topology-pes-cache]) [TransactionTable] Checking transaction GlobalTx:Test-NodeA-24422:22
> 16:31:29,291 TRACE (transport-thread-Test-NodeC-p181-t4:[Topology-pes-cache]) [TransactionTable] No remote transactions pertain to originator(s) who have left the cluster.
> 16:31:29,435 DEBUG (testng-Test:[]) [PessimisticTxPartitionAndMergeDuringRollbackTest] Cluster merged
> 16:31:29,436 TRACE (testng-Test:[]) [PessimisticTxPartitionAndMergeDuringRollbackTest] Local tx=[], remote tx=[GlobalTx:Test-NodeA-24422:22], for cache Test-NodeC-35037
> ...
> 16:31:39,446 TRACE (testng-Test:[]) [PessimisticTxPartitionAndMergeDuringRollbackTest] Local tx=[], remote tx=[GlobalTx:Test-NodeA-24422:22], for cache Test-NodeC-35037
> 16:31:39,446 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PessimisticTxPartitionAndMergeDuringRollbackTest.testPrimaryOwnerIsolatedPartitionWithDiscard[DIST_SYNC, DENY_READ_WRITES]
> java.lang.AssertionError: There are pending transactions!
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.14.3.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.14.3.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:250) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:390) ~[test-classes/:?]
> at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:947) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:101) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:83) ~[test-classes/:?]
> at org.infinispan.partitionhandling.PessimisticTxPartitionAndMergeDuringRollbackTest.testPrimaryOwnerIsolatedPartitionWithDiscard(PessimisticTxPartitionAndMergeDuringRollbackTest.java:43) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10952) InfinispanExtenionIT fails
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10952?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10952:
------------------------------------------
Sprint: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38)
> InfinispanExtenionIT fails
> ---------------------------
>
> Key: ISPN-10952
> URL: https://issues.redhat.com/browse/ISPN-10952
> Project: Infinispan
> Issue Type: Bug
> Components: Integration , Test Suite
> Reporter: Tristan Tarrant
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.1.0.Beta1
>
>
> {{ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.datagrid-infinispan.infinispan_container: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan.infinispan_container: Failed to start service
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:170)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:267)
> at org.infinispan.extension:ispn-10.0@10.1.0-SNAPSHOT//org.jboss.as.clustering.infinispan.DefaultCacheContainer.<init>(DefaultCacheContainer.java:47)
> at org.infinispan.extension:ispn-10.0@10.1.0-SNAPSHOT//org.jboss.as.clustering.infinispan.subsystem.CacheContainerBuilder.start(CacheContainerBuilder.java:97)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Failed to construct component org.infinispan.executors.async, path org.infinispan.executors.async
> << org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifier
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.doInstantiateWrapper(BasicComponentRegistryImpl.java:189)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.instantiateWrapper(BasicComponentRegistryImpl.java:176)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent0(BasicComponentRegistryImpl.java:141)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.WireContext.get(WireContext.java:20)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.notifications.impl.CorePackageImpl$1.wire(CorePackageImpl.java:27)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.notifications.impl.CorePackageImpl$1.wire(CorePackageImpl.java:24)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeInjection(BasicComponentRegistryImpl.java:334)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeInjection(BasicComponentRegistryImpl.java:342)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.doWireWrapper(BasicComponentRegistryImpl.java:231)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:212)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.registerComponent(BasicComponentRegistryImpl.java:371)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:123)
> ... 11 more
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000566: Thread Pool Factory org.infinispan.executors.async is blocking, but this pool requires non blocking threads
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.NamedExecutorsFactory.createExecutorService(NamedExecutorsFactory.java:104)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.NamedExecutorsFactory.construct(NamedExecutorsFactory.java:75)
> at org.infinispan.core:ispn-10.0@10.1.0-SNAPSHOT//org.infinispan.factories.impl.BasicComponentRegistryImpl.doInstantiateWrapper(BasicComponentRegistryImpl.java:186)
> ... 22 more
> }}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10960) Add SerializationContextInitializer lookup to Server Extensions
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10960?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10960:
------------------------------------------
Sprint: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38)
> Add SerializationContextInitializer lookup to Server Extensions
> ---------------------------------------------------------------
>
> Key: ISPN-10960
> URL: https://issues.redhat.com/browse/ISPN-10960
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.0.1.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> To utilise a SerializationContextInitializer on the server it's necessary for the implementation to be specified via the xml configuration. However, it should be possible to utilise the Server's Extensions to automatically load and configure any {{SerializationContextInitializer}} implementations that are placed on the servers classpath by the user. This will remove a configuration step when utilising the normal server, but will have the bigggest impact on the server image, as it will be possible for users to mount a volume with the jar(s) containing the desired {{SerializationContextInitializer}} implementations without changing the xml.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10966) StateTransferLockImpl.topologyFuture should complete exceptionally after stop
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10966?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10966:
------------------------------------------
Sprint: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38)
> StateTransferLockImpl.topologyFuture should complete exceptionally after stop
> -----------------------------------------------------------------------------
>
> Key: ISPN-10966
> URL: https://issues.redhat.com/browse/ISPN-10966
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.0.CR1
>
>
> When a cache is shutting down, the topology id is increased to {{Integer.MAX_VALUE}}.
> If a component uses {{StateTransferLock.topologyUpdate()}} to retry in the next topology and doesn't explicitly check if the cache is running, it could retry 2^^31 times before giving up.
> This causes {{StreamDistPartitionHandlingTest.clearContent}} to hang randomly:
> {noformat}
> 11:58:14,655 TRACE (testng-Test:[]) [StateTransferLockImpl] Signalling topology 2147483647 is installed
> 11:58:14,655 TRACE (testng-Test:[]) [ClusterPublisherManagerImpl] Segments {0-3 8 12 21-22 25-26 29 31 35 37-39 41-42 47 52-54 56-58 73-75 77 85 93-95 97-99 104-105 107 118 121-122 126-129 133 140 145 149 151-154 161 167-168 170-171 177-178 186 189-190 195-196 199-205 212-214 216-217 221-222 224 226-227 232-233 243-244} not completed - retrying
> 11:58:14,655 TRACE (testng-Test:[]) [ClusterPublisherManagerImpl] Retrying segments {0-3 8 12 21-22 25-26 29 31 35 37-39 41-42 47 52-54 56-58 73-75 77 85 93-95 97-99 104-105 107 118 121-122 126-129 133 140 145 149 151-154 161 167-168 170-171 177-178 186 189-190 195-196 199-205 212-214 216-217 221-222 224 226-227 232-233 243-244} after 16 is installed for Test-NodeA-12596#7046
> ...
> 12:03:16,127 TRACE (testng-Test:[]) [ClusterPublisherManagerImpl] Segments {0-3 8 12 21-22 25-26 29 31 35 37-39 41-42 47 52-54 56-58 73-75 77 85 93-95 97-99 104-105 107 118 121-122 126-129 133 140 145 149 151-154 161 167-168 170-171 177-178 186 189-190 195-196 199-205 212-214 216-217 221-222 224 226-227 232-233 243-244} not completed - retrying
> 12:03:16,127 TRACE (testng-Test:[]) [ClusterPublisherManagerImpl] Retrying segments {0-3 8 12 21-22 25-26 29 31 35 37-39 41-42 47 52-54 56-58 73-75 77 85 93-95 97-99 104-105 107 118 121-122 126-129 133 140 145 149 151-154 161 167-168 170-171 177-178 186 189-190 195-196 199-205 212-214 216-217 221-222 224 226-227 232-233 243-244} after 16 is installed for Test-NodeA-12596#7046
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10922) StateTransferLinkFailuresTest random failures
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10922?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10922:
------------------------------------------
Sprint: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38)
> StateTransferLinkFailuresTest random failures
> ---------------------------------------------
>
> Key: ISPN-10922
> URL: https://issues.redhat.com/browse/ISPN-10922
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.0.Beta1
>
>
> {{StateTransferLinkFailuresTest.testLinkBrokenDuringStateTransfer()}} tests that xsite state transfer eventually finishes when the link between sites is down. It simulates an exception in {{backupRemotely()}} and waits for 1 minute for state transfer to finish.
> The problem is that the default xsite state transfer retry configuration is to retry 30 times, waiting 2 seconds between retries. That means it's very possible the test will give up waiting on state transfer to finish just before state transfer finishes.
> {noformat}
> 21:43:02,524 DEBUG (transport-thread-Test-NodeA-p4484-t1:[]) [XSiteStateProviderImpl] [X-Site State Transfer - NYC-2] start DataContainer iteration
> 21:43:02,564 DEBUG (transport-thread-Test-NodeA-p4484-t1:[]) [XSiteStateProviderImpl] Sending chunk to site 'NYC-2'. Chunk contains [XSiteState{key=k_2, value=v_2, metadata=EmbeddedMetadata{version=null}}, XSiteState{key=k_4, value=v_4, metadata=EmbeddedMetadata{version=null}}]
> 21:44:02,579 TRACE (transport-thread-Test-NodeA-p4484-t1:[]) [RetryOnFailureXSiteCommand] Exception Response received. Exception is org.infinispan.util.concurrent.TimeoutException: induced timeout!
> 21:44:02,611 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.xsite.statetransfer.failures.StateTransferLinkFailuresTest.testLinkBrokenDuringStateTransfer[null, tx=false]
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.14.3.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.14.3.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:250) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:232) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:208) ~[test-classes/:?]
> at org.infinispan.xsite.AbstractXSiteTest.assertEventuallyInSite(AbstractXSiteTest.java:193) ~[test-classes/:?]
> at org.infinispan.xsite.statetransfer.failures.StateTransferLinkFailuresTest.testLinkBrokenDuringStateTransfer(StateTransferLinkFailuresTest.java:89) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10906) JGroupsTransport instance is reused in tests
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-10906?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-10906:
------------------------------------------
Sprint: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38, DataGrid Sprint #39 (was: DataGrid Sprint #36, DataGrid Sprint #37, DataGrid Sprint #38)
> JGroupsTransport instance is reused in tests
> --------------------------------------------
>
> Key: ISPN-10906
> URL: https://issues.redhat.com/browse/ISPN-10906
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.0.CR1
>
>
> The {{TRANSPORT}} {{AttributeDefinition}} uses {{IdentityAttributeCopier}}, which means that when a test uses {{GlobalConfigurationBuilder.read()}} to make a clone of the global configuration it keeps using the same {{JGroupsTransport}} instance. Both cache managers sort of work, but usually not as intended.
> We should detect when {{JGroupsTransport}}'s dependencies are injected twice and throw an exception. We should also consider changing the {{TRANSPORT}} copier to {{SimpleInstanceAttributeCopier}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months