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-...
Hoang,
On Sat, May 31, 2014 at 12:05 AM, Peter Palaga <ppalaga(a)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