Bug 1103304 - testMemoryLeakWithMultiThread fails sometimes
Summary: testMemoryLeakWithMultiThread fails sometimes
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: Portal
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER04
: 6.2.0
Assignee: Peter Palaga
QA Contact: Tomas Kyjovsky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-30 16:55 UTC by Peter Palaga
Modified: 2025-02-10 03:35 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-02-10 03:35:57 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker GTNPORTAL-3500 0 Major Resolved testMemoryLeakWithMultiThread fails sometimes 2014-08-12 11:28:46 UTC

Description Peter Palaga 2014-05-30 16:55:05 UTC
Description of problem: org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread() fails in some cases. The stack trace:
junit.framework.AssertionFailedError
	at junit.framework.Assert.fail(Assert.java:48)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at junit.framework.Assert.assertTrue(Assert.java:27)
	at org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...

The line where it fails is 

assertTrue(cache.getCacheSize() <= 10);

Version-Release number of selected component (if applicable):
JBoss Portal 6.2.0.ER2

How reproducible:
Sometimes, 1/10 or even less. Happens both on Jenkins and desktop.

Steps to Reproduce:
Not sure. It happens randomly. Perhaps overloading the machine with some CPU-intensive task might help. Just build the exo.portal.component.web.server artifact with tests.

Actual results:
Test fails

Expected results:
Not sure if the subject under the test is broken or the test itself.

Additional info:

Comment 2 Peter Palaga 2014-06-20 19:27:25 UTC
Solved by removing the test case: https://github.com/gatein/gatein-portal/commit/6ff96e9f924688ce14ee88517e1e179961b6363c

Justification by Trong (cited from https://issues.jboss.org/browse/GTNPORTAL-3500): The root problem is that it's using ConcurrentFIFOExoCache for holding resources temporarily. This test is to assert the cached objects size == max size BUT in the case of multi-threading, it can not be 100% sure that cacheSize == maxSize at any time as it needs a little time to execute the cache eviction. ===> for me, it's acceptable.

Comment 4 PnT Account Manager 2017-12-08 15:06:45 UTC
Employee 'fkiss' has left the company.

Comment 5 Red Hat Bugzilla 2025-02-10 03:35:57 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


Note You need to log in before you can comment on or make changes to this bug.