I looked through the kafka JmxReporter class (and other kafka classes
that we use) and couldn't spot anything
that would prevent the Mbeans from being unregistered. The obvious
implication would be that we don't
properly clean up kafka classes, but that code looks good as well.
So at the moment I'm a bit stumped as to why this is happening.
For reproducing the problem, could you answer the following questions?
1. How do you kill the job?
2. Do you have any Flink reporter configured?
3. Does this only happen on Kubernetes?
4. Does this also happen with parent-first classloading?
On 09.02.2018 14:19, Edward wrote:
I applied the change in the pull request associated with that Kafka bug, and
unfortunately it didn't resolve anything. It doesn't unregister any
additional MBeans which are created by Kafka's JmxRepository -- it is just a
fix to the remove mbeans from Kafka's cache of mbeans (i.e. it is doing
cleanup within the job's ChildFirst classloader, not the bootstrap/App
classloader where the strong reference exists).
--
Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/
