Still digging into this. It appears that the SessionStats are held by StatisticsManager in the RepositoryImpl class, and are not being held by unclosed Sessions. I haven¹t been able to determine when they should be released, but I assume it is in one of the executors that Oak opens. Possibly related is the fact that on shutdown we have dozens of dangling threads, evidenced in the Tomcat logs:
WARNING: The web application [red-oak-cms] appears to have started a thread named [oak-scheduled-executor-744] 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.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awai tNanos(AbstractQueuedSynchronizer.java:2078) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(Sch eduledThreadPoolExecutor.java:1129) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(Sch eduledThreadPoolExecutor.java:809) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:10 66) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: 1127) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java :617) java.lang.Thread.run(Thread.java:745) This leads me to believe that something is causing the executor threads to hang and not complete their cleanup. On shutdown, we attempt to clean up the application by calling: ((RepositoryImpl) repository).shutdown(); ns.dispose(); Jim Tully
