[ https://issues.apache.org/jira/browse/FLINK-32203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated FLINK-32203: ----------------------------------- Labels: pull-request-available (was: ) > Potential ClassLoader memory leak due to log4j configuration > ------------------------------------------------------------ > > Key: FLINK-32203 > URL: https://issues.apache.org/jira/browse/FLINK-32203 > Project: Flink > Issue Type: Bug > Reporter: Oleksandr Nitavskyi > Priority: Major > Labels: pull-request-available > Attachments: classloader_leak.png, > stack_trace_example_with_log4j_creation_on_job_reload.log > > > *Context* > We have encountered a memory leak related to ClassLoaders in Apache Flink. > ChildFirstClassLoader is not properly garbage collected, when job is being > restarted. > Heap Dump has shown that Log4j starts a configuration watch thread, which > then has Strong reference to ChildFirstClassLoader via AccessControlContext. > Since thread is never stopped, ChildFirstClassLoader is never cleaned. > Removal monitorInterval introduced in FLINK-20510 helps to mitigate the > issue, I believe it could be applied to log4j config by default. > *How to reproduce* > Deploy Flink job, which uses Hadoop File System (e.g. s3a). Redeploy the job > -> in Task Manager dump you should see multiple Log4jThreads > *AC* > We have a configuration which doesn't lead easy to memory leak with default > configuration for Flink users. -- This message was sent by Atlassian Jira (v8.20.10#820010)