Thanks for merging. Buildbot is succeeding again.
So my testng changes help speed up the tests and improve the heap usage
(worth adding the changes in at some point) but it didn't solve the root
cause. I see these in the logs:
SEVERE [http-nio-37745-exec-211]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [24366694ab54ddc83623ef655667ac266c465c4] created a
ThreadLocal with key of type [java.lang.InheritableThreadLocal] (value
[java.lang.InheritableThreadLocal@413afe5a]) and a value of type
[org.testng.internal.TestResult] (value [[TestResult name=testEventsFired
status=SUCCESS
method=RequestScopeEventMessageDeliveryTest.testEventsFired()[pri:0,
instance:org.jboss.cdi.tck.tests.context.request.event.jms.RequestScopeEventMessageDeliveryTest@71e20c1]
output={null}]]) but failed to remove it when the web application was
stopped. Threads are going to be renewed over time to try and avoid a
probable memory leak.
WARNING [http-nio-37745-exec-43]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
web application [f171a3d3289dcf8237159d936219ff9c87d85db] appears to have
started a thread named [pool-29-thread-1] but has failed to stop it. This is
very likely to create a memory leak. Stack trace of thread:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
Am trying to get to pin point but things are slow here so it's taking a bit.
--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
