This is a follow on to the discussion in #8014. The problem here is that the object cleaner thread is considered an internal implementation detail yet its details can leak.
In Elasticearch, we have a thread leak control that detects threads created by a test suite but are not stopped at the end of the test suite. This is part of broader detection in our test framework for leaked resources of any kind.
The problem here is that because the object cleaner thread can not be stopped or otherwise controlled, it fails our thread leak control as it will always be running in nearly any test suite that interacts with Netty.
We tried to upgrade to Netty 4.1.25 and it was quite a mess because of this thread: elastic/elasticsearch#31232. We tried putting a filter in place on relevant test suites but we ultimately decided the surface area here is too large and this is gross anyway, especially without any public API guarantees about the thread. We have ultimately decided to revert this upgrade (elastic/elasticsearch#31282) and are now considering ourselves blocked on upgrading until a better solution to the object cleaner thread problem can be found.
We are looking for a way to shutdown the cleaner (ideally by adding something to our shutdown code (HTTP, TCP) so that all tests pick it up and it's not as messy as needing to filter the thread from leak control everywhere).
Alternatively, a way to avoid the use of the object cleaner would be acceptable too.
This is a follow on to the discussion in #8014. The problem here is that the object cleaner thread is considered an internal implementation detail yet its details can leak.
In Elasticearch, we have a thread leak control that detects threads created by a test suite but are not stopped at the end of the test suite. This is part of broader detection in our test framework for leaked resources of any kind.
The problem here is that because the object cleaner thread can not be stopped or otherwise controlled, it fails our thread leak control as it will always be running in nearly any test suite that interacts with Netty.
We tried to upgrade to Netty 4.1.25 and it was quite a mess because of this thread: elastic/elasticsearch#31232. We tried putting a filter in place on relevant test suites but we ultimately decided the surface area here is too large and this is gross anyway, especially without any public API guarantees about the thread. We have ultimately decided to revert this upgrade (elastic/elasticsearch#31282) and are now considering ourselves blocked on upgrading until a better solution to the object cleaner thread problem can be found.
We are looking for a way to shutdown the cleaner (ideally by adding something to our shutdown code (HTTP, TCP) so that all tests pick it up and it's not as messy as needing to filter the thread from leak control everywhere).
Alternatively, a way to avoid the use of the object cleaner would be acceptable too.