Improve the concurrent behaviour of the tracking event processor. #2311
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Turns out there were a few edge cases left. I also restructured a bit, to make both workers more the same. Now when a worker 'switches jobs' it will always be from the cleanup/finally.
The main left over problem was that the
AtomicBoolean
for theworkLauncherRunning
was set from the worker thread. So it could happen that it would switch to true, after callingstart()
, which in turn prevented the thread to be stopped atshutdown()
which in turn caused an error when callingstart()
again, since it was not properly shutdown, as expected.Additionally a
removeThread(String name)
method was added, where the expectation is that it will never actually log the message, but would provide valuable information if it does.This was locally tested as fix for #2293, 10.000 times stopping and starting worked without problems, where the latest release would give an error around 30-50 times.