6
Utilizzando ehCache 2.4.4, mi sembra di essere entrato in un deadlock sull'oggetto Segmento ehCache. Da altri logging, so che il 'thread in attesa', 1694 ha eseguito l'ultima operazione circa 9 ore prima che venisse generata questa traccia dello stack. Nel frattempo, 1696 ha fatto un sacco di altri lavori, quindi questa serratura è sicuramente tenuta in modo errato.Come posso aggirare questo apparente blocco critico di EhCache?
Sono abbastanza sicuro di non bloccare direttamente le istanze di segmento direttamente, quindi presumo che si tratti di un problema interno alla libreria. Qualche idea?
"Model Executor - 1696" Id=1696 in TIMED_WAITING on lock=java.u[email protected]92eb1ed
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown Source)
at java.util.concurrent.PriorityBlockingQueue.poll(Unknown Source)
at com.rtrms.application.modeling.local.BlockingTaskList.takeTask(BlockingTaskList.java:20)
at com.rtrms.application.modeling.local.ModelExecutor.executeNextTask(ModelExecutor.java:71)
at com.rtrms.application.modeling.local.ModelExecutor.run(ModelExecutor.java:46)
Locked synchronizers: count = 1
- [email protected]3d767f
"Model Executor - 1694" Id=1694 in WAITING on loc[email protected]4a3d767f
owned by Model Executor - 1696 Id=1696
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(Unknown Source)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(Unknown Source)
at net.sf.ehcache.store.compound.Segment.unretrievedGet(Segment.java:248)
at net.sf.ehcache.store.compound.CompoundStore.unretrievedGet(CompoundStore.java:191)
at net.sf.ehcache.store.compound.impl.DiskPersistentStore.containsKeyInMemory(DiskPersistentStore.java:72)
at net.sf.ehcache.Cache.searchInStoreWithStats(Cache.java:1884)
at net.sf.ehcache.Cache.get(Cache.java:1549)
at com.rtrms.amoeba.cache.DistributedModeledSecurities.get(DistributedModeledSecurities.java:57)
at com.rtrms.amoeba.modeling.AssertPersistedModeledSecurities.get(AssertPersistedModeledSecurities.java:44)
at com.rtrms.application.modeling.tasks.ExpandableModelingTask.getNextUnexecutedTask(ExpandableModelingTask.java:35)
at com.rtrms.application.modeling.local.BlockingTaskList.takeTask(BlockingTaskList.java:36)
at com.rtrms.application.modeling.local.ModelExecutor.executeNextTask(ModelExecutor.java:71)
at com.rtrms.application.modeling.local.ModelExecutor.run(ModelExecutor.java:46)
Locked synchronizers: count = 0
Si scopre che questa domanda non è valida. Ho interpretato questa documentazione (http://ehcache.org/documentation/user-guide/jta#performance) come ad indicare che i blocchi espliciti non utilizzano il blocco basato sul segmento, ma risulta che non è vero. Questo deadlock è stato causato dal mio codice, c'era una versione di blocco che non si trovava in un blocco finally(). – sharakan
perché non rispondi alla tua stessa domanda se l'hai già capito in modo che non sia presente nelle domande senza risposta? – xmoex