C0urante commented on PR #12666: URL: https://github.com/apache/kafka/pull/12666#issuecomment-1253949072
@divijvaidya Thank you for your thoughts. I don't quite agree that attempting to terminate the JVM is a symptom rather than the root cause, since there are cases where these attempts occur without threads being leaked (one such case was touched on in https://github.com/apache/kafka/pull/9698). In addition, the main issue here is that these attempts tend to crop up only during CI builds and not locally, in which case the cost of allowing the JVM to be terminated is higher as debugging is harder and the build attempt is rendered useless. I'm also not very worried about the deprecation of the `SecurityManager` API since it's unlikely that the API will be fully removed without adding in an alternative way to intercept calls to terminate the JVM; this use case is called out repeatedly in JEP-411 as a valuable one. I've updated the PR to be safe with Java 18 with some small conditional logic in the Gradle build file. This should lay some decent groundwork for the future if we want to apply different means of intercepting calls to terminate the JVM depending on which Java version we're building with. That said, if you have the time to develop and implement an alternative proposal, I'd be happy to review a POC. I'm not certain we really can track thread creation and termination during tests without a serious refactoring of the code base, but if there's a lightweight way to do this, it would probably be worth considering either instead of or in addition to hardening our testing logic against JVM termination. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
