[JBoss JIRA] (ISPN-8036) TestResourceTracker keeps cache managers alive after they are stopped
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8036?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8036:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5275
> TestResourceTracker keeps cache managers alive after they are stopped
> ---------------------------------------------------------------------
>
> Key: ISPN-8036
> URL: https://issues.jboss.org/browse/ISPN-8036
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.1.0.CR1, 9.0.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Final
>
>
> {{TestCacheManagerFactory.newDefaultCacheManager()}} adds the manager to {{TestResourceTracker}} so if the test doesn't stop it explicitly, {{TestResourceTracker}} will.
> When a test uses {{@CleanupAfterMethod}}, however, the cache managers are stopped and recreated after each method, but the list of resources is only cleared at the end of the test class. If a test has lots of methods, like {{LocalDistributedExecutorTest}} and its subclasses, the stopped managers can use a lot of memory (250KB for each {{ComponentMetadataRepo}}).
> I believe the extra memory usage is causing longer GC pauses, and in turn leads to intermittent test failures in test methods that use short timeouts:
> {noformat}
> 16:58:34,801 ERROR (testng-ReplSyncDistributedExecutorTest:[]) [TestSuiteProgress] Test failed: org.infinispan.distexec.ReplSyncDistributedExecutorTest.testInvokeAnyTimedSleepingTasks
> java.lang.AssertionError: Should have thrown an class java.util.concurrent.TimeoutException
> at org.infinispan.test.Exceptions.assertException(Exceptions.java:21) ~[test-classes/:?]
> at org.infinispan.test.Exceptions.expectException(Exceptions.java:92) ~[test-classes/:?]
> at org.infinispan.distexec.LocalDistributedExecutorTest.testInvokeAnyTimedSleepingTasks(LocalDistributedExecutorTest.java:269) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ISPN-8036) TestResourceTracker keeps cache managers alive after they are stopped
by Dan Berindei (JIRA)
Dan Berindei created ISPN-8036:
----------------------------------
Summary: TestResourceTracker keeps cache managers alive after they are stopped
Key: ISPN-8036
URL: https://issues.jboss.org/browse/ISPN-8036
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 9.0.3.Final, 9.1.0.CR1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.1.0.Final
{{TestCacheManagerFactory.newDefaultCacheManager()}} adds the manager to {{TestResourceTracker}} so if the test doesn't stop it explicitly, {{TestResourceTracker}} will.
When a test uses {{@CleanupAfterMethod}}, however, the cache managers are stopped and recreated after each method, but the list of resources is only cleared at the end of the test class. If a test has lots of methods, like {{LocalDistributedExecutorTest}} and its subclasses, the stopped managers can use a lot of memory (250KB for each {{ComponentMetadataRepo}}).
I believe the extra memory usage is causing longer GC pauses, and in turn leads to intermittent test failures in test methods that use short timeouts:
{noformat}
16:58:34,801 ERROR (testng-ReplSyncDistributedExecutorTest:[]) [TestSuiteProgress] Test failed: org.infinispan.distexec.ReplSyncDistributedExecutorTest.testInvokeAnyTimedSleepingTasks
java.lang.AssertionError: Should have thrown an class java.util.concurrent.TimeoutException
at org.infinispan.test.Exceptions.assertException(Exceptions.java:21) ~[test-classes/:?]
at org.infinispan.test.Exceptions.expectException(Exceptions.java:92) ~[test-classes/:?]
at org.infinispan.distexec.LocalDistributedExecutorTest.testInvokeAnyTimedSleepingTasks(LocalDistributedExecutorTest.java:269) ~[test-classes/:?]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ISPN-8036) TestResourceTracker keeps cache managers alive after they are stopped
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8036?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8036:
-------------------------------
Status: Open (was: New)
> TestResourceTracker keeps cache managers alive after they are stopped
> ---------------------------------------------------------------------
>
> Key: ISPN-8036
> URL: https://issues.jboss.org/browse/ISPN-8036
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.1.0.CR1, 9.0.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Final
>
>
> {{TestCacheManagerFactory.newDefaultCacheManager()}} adds the manager to {{TestResourceTracker}} so if the test doesn't stop it explicitly, {{TestResourceTracker}} will.
> When a test uses {{@CleanupAfterMethod}}, however, the cache managers are stopped and recreated after each method, but the list of resources is only cleared at the end of the test class. If a test has lots of methods, like {{LocalDistributedExecutorTest}} and its subclasses, the stopped managers can use a lot of memory (250KB for each {{ComponentMetadataRepo}}).
> I believe the extra memory usage is causing longer GC pauses, and in turn leads to intermittent test failures in test methods that use short timeouts:
> {noformat}
> 16:58:34,801 ERROR (testng-ReplSyncDistributedExecutorTest:[]) [TestSuiteProgress] Test failed: org.infinispan.distexec.ReplSyncDistributedExecutorTest.testInvokeAnyTimedSleepingTasks
> java.lang.AssertionError: Should have thrown an class java.util.concurrent.TimeoutException
> at org.infinispan.test.Exceptions.assertException(Exceptions.java:21) ~[test-classes/:?]
> at org.infinispan.test.Exceptions.expectException(Exceptions.java:92) ~[test-classes/:?]
> at org.infinispan.distexec.LocalDistributedExecutorTest.testInvokeAnyTimedSleepingTasks(LocalDistributedExecutorTest.java:269) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months