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" <jim.tu...@target.com> 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 >
