Searched on Google with the first line of a JAVA stack trace?

We can recommend more relevant solutions and speed up debugging when you paste your entire stack trace with the exception message. Try a sample exception.

Recommended solutions based on your search

Solutions on the web

via Stack Overflow by vijar
, 1 year ago
Failed to acquire the lock in 60 seconds. Possible reasons: - The lock was not released by the previous holder. If you use contexts API, for example map.queryContext(key), in a try-with-resources block. - This Chronicle Map (or Set) instance is
via GitHub by leventov
, 1 year ago
Failed to acquire the lock in 60 seconds. Possible reasons: - The lock was not released by the previous holder. If you use contexts API, for example map.queryContext(key), in a try-with-resources block. - This Chronicle Map (or
java.lang.RuntimeException: Failed to acquire the lock in 60 seconds.
Possible reasons:
 - The lock was not released by the previous holder. If you use contexts API,
 for example map.queryContext(key), in a try-with-resources block.
 - This Chronicle Map (or Set) instance is persisted to disk, and the previous
 process (or one of parallel accessing processes) has crashed while holding
 this lock. In this case you should use ChronicleMapBuilder.recoverPersistedTo() procedure
 to access the Chronicle Map instance.
 - A concurrent thread or process, currently holding this lock, spends
 unexpectedly long time (more than 60 seconds) in
 the context (try-with-resource block) or one of overridden interceptor
 methods (or MapMethods, or MapEntryOperations, or MapRemoteOperations)
 while performing an ordinary Map operation or replication. You should either
 redesign your logic to spend less time in critical sections (recommended) or
 acquire this lock with tryLock(time, timeUnit) method call, with sufficient
 time specified.
 - Segment(s) in your Chronicle Map are very large, and iteration over them
 takes more than 60 seconds. In this case you should
 acquire this lock with tryLock(time, timeUnit) method call, with longer
 timeout specified.
 - This is a dead lock. If you perform multi-key queries, ensure you acquire
 segment locks in the order (ascending by segmentIndex()), you can find
 an example here: https://github.com/OpenHFT/Chronicle-Map#multi-key-queries	at net.openhft.chronicle.hash.impl.BigSegmentHeader.deadLock(BigSegmentHeader.java:59)	at net.openhft.chronicle.hash.impl.BigSegmentHeader.updateLock(BigSegmentHeader.java:231)	at net.openhft.chronicle.map.impl.CompiledMapIterationContext$UpdateLock.lock(CompiledMapIterationContext.java:768)	at net.openhft.chronicle.map.impl.CompiledMapIterationContext.forEachSegmentEntryWhile(CompiledMapIterationContext.java:3810)	at net.openhft.chronicle.map.impl.CompiledMapIterationContext.forEachSegmentEntry(CompiledMapIterationContext.java:3816)	at net.openhft.chronicle.map.ChronicleMapIterator.fillEntryBuffer(ChronicleMapIterator.java:61)	at net.openhft.chronicle.map.ChronicleMapIterator.hasNext(ChronicleMapIterator.java:77)	at java.lang.Iterable.forEach(Iterable.java:74)