6
Usando ehCache 2.4.4, parece que me he metido en un punto muerto en el objeto del segmento ehCache. De otro registro, sé que el 'hilo de espera', 1694 último funcionó cualquier cosa 9 horas antes de que se generara este rastro de la pila. Mientras tanto, 1696 se ha ido y ha hecho muchos otros trabajos, por lo que esta cerradura definitivamente se mantiene de forma errante.¿Cómo puedo evitar este aparente punto muerto de EhCache?
Estoy bastante seguro de que no estoy bloqueando directamente ninguna instancia del segmento directamente, así que supongo que esto es algún tipo de problema interno de la biblioteca. ¿Algunas ideas?
"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 lock=java.util.concurrent.locks[email protected]
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
Resulta que esta pregunta no es válida. Había interpretado esta documentación (http://ehcache.org/documentation/user-guide/jta#performance) como una indicación de que los bloqueos explícitos no usan el bloqueo basado en segmentos, pero resulta que eso no es cierto. Este interbloqueo fue causado por mi código, hubo una liberación de bloqueo que no estaba en un bloque finally(). – sharakan
¿por qué no respondes tu propia pregunta si ya la has descifrado para que no esté presente en las preguntas sin respuesta? – xmoex