knight6236 commented on issue #12456: URL: https://github.com/apache/seatunnel/issues/12456#issuecomment-5902619531
We investigated a related classloader-retention scenario using SeaTunnel **2.3.13**, **Java 8u342**, and `classloader-cache-mode=false`, with repeated MongoDB → Hive jobs included in our existing E2E matrix. Your observation that `classLoaderCache` returns to zero is important: removing the loader from that cache does not necessarily make it collectible if other objects still retain it. In our reproduction, MAT analysis and source inspection identified additional retention paths involving MongoDB buffer-pool maintenance and Hadoop resources, including `CodecPool`, `ReflectionUtils`, the token renewer `ServiceLoader`, and shared DFS/RPC objects retaining job classloaders through thread context or configuration references. These are findings from **our test environment**; we have not established that every path is present in your heap dump. We implemented targeted cleanup in [[LingFrame SeaTunnel Agent](https://github.com/LingFrame/LingFrame-Seatunnel-Agent)], which we maintain, and compared it against an unmodified SeaTunnel instance. In one completed A/B run, each side executed **105 jobs across a mixed connector matrix**, including MongoDB → Hive. After job completion and forced GC: | Measurement | Without agent | With agent | |---|---:|---:| | Remaining `SeaTunnelChildFirstClassLoader` instances | 567 | 0 | | Metaspace used | ~620 MiB | ~90 MiB | This demonstrates classloader reclamation for that test workload, rather than proof of long-term stability or an upstream fix. Our environment also differs from your separated master/worker deployment and Java version. We have additionally observed intermittent job-status timeouts in CI that remain under investigation. The reproduction and cleanup implementation are available in the repository above for review. We are sharing these results to help narrow the post-release retention paths in this issue. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
