Hi,

I have left eXo for more than one year!

By the way, i remember well that the DownloadService had critical memory leak due to the wrong use of LinkedHashMap as a cache.

https://hoangx281283.wordpress.com/2012/11/18/wrong-use-of-linkedhashmap-causes-memory-leak/

Hoang,



On Sat, May 31, 2014 at 12:05 AM, Peter Palaga <ppalaga@redhat.com> wrote:
Hi Minh, I hope, you are still a part of the team?

This happened to me and other JBoss Portal devs and testers several times recently. From quickly looking at the test, I was not able to tell, what is wrong: (a) the test or (b) the DownloadService has leaks. Could you please have a look?

Here are the detais:
https://issues.jboss.org/browse/GTNPORTAL-3500

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):
GateIn 3.8.x or 3.9.x
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 repeatedly until it fails.
Actual results:
Test fails
Expected results:
Not sure if the subject under the test is broken or the test itself.

Thanks,

Peter



--
Minh Hoang TO

Niteco Vietnam
Cland Tower

156 Xa Dan II, Hanoi, Vietnam