Improve the ThreadGroup of the Janitor #87
Merged
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.
Issue #, if available: #86
Description of changes:
This moves creation of the
Janitor
thread to theLoader
which causes it to exist in a more logicalThreadGroup
rather than associated with whateverThreadGroup
first needs to use a native resource.When Java threads are created they (by default) belong to the ThreadGroup of the creating thread. This can cause problems for ACCP and our customers if the ThreadGroup belongs to a tracked thread pool or similar structure. Previously the Janitor (and associated cleaning threads) was created lazily upon first use. This meant that its thread(s) would be associated with whatever customer ThreadGroup first used aspects of ACCP. The change in this PR moves Janitor creation to our main installation/loading logic which will generally be done by threads/ThreadGroups responsible for general system startup and running and thus more appropriate to own the resulting Janitor cleaning thread.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.