You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It 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 FileBasedCachingSameAsRetriever and 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 Semaphore class is really necessary. Especially within the FileBasedCachingSameAsRetriever other, safer methods could be useful.
The text was updated successfully, but these errors were encountered:
The issue is caused by this part of the code being not covered by a try-finally construct. Because of that problem, the 1000 available read permits were lost throughout the time GERBIL was running. As soon as all of them were lost, the service got stuck.
Proposed solution
Fix this part of the class using try-finally.
Go through all other classes using Semaphores and check them for the same issue.
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
XXX
is one of the in-build annotatorA-x
is a NIF-based webservice wherex
denotes an IDD-x
is 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
FileBasedCachingSameAsRetriever
and 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
Semaphore
class is really necessary. Especially within theFileBasedCachingSameAsRetriever
other, safer methods could be useful.The text was updated successfully, but these errors were encountered: