Worker threads get stuck waiting for Semaphore #348
Labels
Comments
|
The proposed solution above does not work in this case, since the class makes use of two Semaphores private static final int MAX_CONCURRENT_READERS = 1000;
private Semaphore cacheReadMutex = new Semaphore(MAX_CONCURRENT_READERS);
private Semaphore cacheWriteMutex = new Semaphore(1);In line try {
cacheReadMutex.acquire();
} catch (InterruptedException e) {
LOGGER.error("Exception while waiting for read mutex. Returning null.", e);
return null;
}
...
cacheReadMutex.release();
return result;The issue is caused by this part of the code being not covered by a Proposed solution
|
MichaelRoeder
added a commit
that referenced
this issue
May 1, 2020
Fixed #348 by ensuring that semaphore permits are released.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Error description
All worker threads seem to be stuck while preparing the datasets or doing some post processing of the received annotator results.
The stack traces of the workers:
Summary of stack traces
XXXis one of the in-build annotatorA-xis a NIF-based webservice wherexdenotes an IDD-xis an uploaded datasetIt looks like threads 1, 2, 3, 4 and 7 wait for thread 10 to finish the initialisation of the ACE2004 dataset. This seems to be fine. However, the threads 4, 6, 8, 9, 10, 11 and 12 seem to wait to get access to the
FileBasedCachingSameAsRetrieverand it is unclear which thread has not released the Semaphore, before.There is no Exception in the logs that seems to be related to that. GERBIL is configured to use 12 worker threads and all of them are still alive - so no thread crashed.
Proposed solution
It should be checked whether the usage of the
Semaphoreclass is really necessary. Especially within theFileBasedCachingSameAsRetrieverother, safer methods could be useful.The text was updated successfully, but these errors were encountered: