When the Bulk Ingester is configured in such a way that the number of external threads performing the add operation is much higher than maxConcurrentRequests (usually more than 50 to 1), after completing all of the request but the last one, the Bulk Ingester stops.
If there's a flusher thread, it will keep adding requests one by one, and sending them one by one: this is because ~95% of the external threads will get stuck while adding, and a send operation will only free one of those at a time.
Replacing signal() with signalAll() to free the threads is a possible solution, but it's also expensive and considering this is an extreme case it would affect performances for every other case; so the chosen solution is to add another signal() after a successful add operation, assuring that stuck threads will be released quickly if the condition that got them stuck no longer applies.
When the Bulk Ingester is configured in such a way that the number of external threads performing the
addoperation is much higher thanmaxConcurrentRequests(usually more than 50 to 1), after completing all of the request but the last one, the Bulk Ingester stops.If there's a flusher thread, it will keep adding requests one by one, and sending them one by one: this is because ~95% of the external threads will get stuck while adding, and a
sendoperation will only free one of those at a time.Replacing
signal()withsignalAll()to free the threads is a possible solution, but it's also expensive and considering this is an extreme case it would affect performances for every other case; so the chosen solution is to add anothersignal()after a successfuladdoperation, assuring that stuck threads will be released quickly if the condition that got them stuck no longer applies.Should fix #651