Hi, Thanks for reporting this back.
For completeness sake, the SessionStats instances are registered for each session scheduled with a one minute delay. This is to avoid cluttering the name space with many short lived instances. When a session logs out the associated SessionStats instance is also discarded or if one minute has not passed yet the pending registration for the SessionStats instance is cancelled. Michael On 18.10.15 5:43 , Jim.Tully wrote: > I apologize for the noise. Digging deeper into my code, I discovered that > I was not logging out of the sessions as I thought I was. Once I resolved > that, the memory issue disappeard. > > Jim Tully > > > On 10/17/15, 2:21 PM, "Jim.Tully" <[email protected]> wrote: > >> 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 >> >
