Ehcache - Weblogic - OutOfMemory

[Paulo Augusto Pimenta Filho]

Hi,

I'm having an out of memory issue and I suspect that is related to cache.

It is an web app (portal) in weblogic 10

Output from weblogic:

Exception in thread "getSubjectCache.data" java.lang.OutOfMemoryError: getNewTla

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter(AbstractQueuedSynchronizer.java:1801)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1983)

at java.util.concurrent.DelayQueue.take(DelayQueue.java:160)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)

at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:662)

<Jul 16, 2015 7:13:21 PM BRT> <Error> <Kernel> <BEA-000802> <ExecuteRequest failed

 java.lang.OutOfMemoryError: getNewTla.

java.lang.OutOfMemoryError: getNewTla

at weblogic.wsee.wstx.internal.ForeignRecoveryContextManager$ContextTimerListener.timerExpired(ForeignRecoveryContextManager.java:108)

at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)

at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)

at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)

at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Thread dump:

It has hundreds of threads like this one in different .data 

"clientToken.data" id=474 idx=0x63c tid=4975 prio=5 alive, parked, native_blocked

    -- Parking to wait for: java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject@0xfa4397e0

    at jrockit/vm/Locks.park0(J)V(Native Method)

    at jrockit/vm/Locks.park(Locks.java:2230)

    at sun/misc/Unsafe.park(ZJ)V(Native Method)

    at java/util/concurrent/locks/LockSupport.park(LockSupport.java:156)

    at java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)

    at java/util/concurrent/DelayQueue.take(DelayQueue.java:160)[optimized]

    at java/util/concurrent/ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)[inlined]

    at java/util/concurrent/ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)[optimized]

    at java/util/concurrent/ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)

    at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

    at java/lang/Thread.run(Thread.java:662)[optimized]

    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)

    -- end of trace

 

"flatAccountCache.data" id=609 idx=0x6c0 tid=6595 prio=5 alive, parked, native_blocked, daemon

    -- Parking to wait for: java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject@0xf6a6ccf8

    at jrockit/vm/Locks.park0(J)V(Native Method)

    at jrockit/vm/Locks.park(Locks.java:2230)

    at sun/misc/Unsafe.park(ZJ)V(Native Method)

    at java/util/concurrent/locks/LockSupport.park(LockSupport.java:156)

    at java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)

    at java/util/concurrent/DelayQueue.take(DelayQueue.java:160)[optimized]

    at java/util/concurrent/ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)[inlined]

    at java/util/concurrent/ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)[optimized]

    at java/util/concurrent/ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)[optimized]

    at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

    at java/lang/Thread.run(Thread.java:662)[optimized]

    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)

    -- end of trace

Most of ehcache configurations are overflowToDisk="true" diskPersistent="false"

I solved the problem changing the Xmx from 512 M to 1024 M, but I would like to understand why the cache configuration appers in thread dump Ex: "flatAccountCache.data"

1. What version of Ehcache you are currently using; 2.5.1
   
   
2. Paste the configuration for the Cache/CacheManager you have an issue with;

<?xml version="1.0" encoding="UTF-8"?>

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"

updateCheck="false">

<cache name="userInfoServiceCache" eternal="false" maxElementsInMemory="10000"

overflowToDisk="true" diskPersistent="false" timeToIdleSeconds="0"

timeToLiveSeconds="2592000" statistics="true"

memoryStoreEvictionPolicy="LRU"></cache

[Alex Snaps]

These threads are related to disk persistent/overflowing cache instances. iirc you get one thread for each of these Caches. 

Now, wrt the OOME, obviously Ehcache increases the pressure on the heap as, given your version/config, bunch gets stored on-heap. More importantly disk overflow/persistence happens asynchronously, so that heap does incur a hit, if maybe only in spikes, during high mutation phases...  

--
You received this message because you are subscribed to the Google Groups "ehcache-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-user...@googlegroups.com.
To post to this group, send email to ehcach...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/9a3f448a-546e-4251-a83a-e6aaada5f6c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.