Bug 1103304

Summary:	testMemoryLeakWithMultiThread fails sometimes
Product:	[JBoss] JBoss Enterprise Portal Platform 6	Reporter:	Peter Palaga <ppalaga>
Component:	Portal	Assignee:	Peter Palaga <ppalaga>
Status:	CLOSED UPSTREAM	QA Contact:	Tomas Kyjovsky <tkyjovsk>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.2.0	CC:	epp-bugs
Target Milestone:	ER04
Target Release:	6.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-02-10 03:35:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.