DanielLeens commented on issue #12456: URL: https://github.com/apache/seatunnel/issues/12456#issuecomment-6123941681
Thanks for adding the 0/5/10-job comparison and the complete GC-root paths. This is material new evidence: the repeated root through Hadoop `ReflectionUtils.CONSTRUCTOR_CACHE` is a process-wide static cache holding a class defined by the released connector class loader. I checked current `dev` at `4ae4fee30165e9f082f80b05ec5a8f3bb810b474`. It contains the two #12456 cleanup commits, `35b9d5e26d2` and `097101c21be`, which clean the MongoDB pruner, `WritableComparator`, and the four `CodecPool` registries when the last reference to a non-cached job loader is released. The cleaner does not currently handle `ReflectionUtils.CONSTRUCTOR_CACHE`, so the new growing root is not covered by those changes. I therefore cannot treat the issue as resolved yet. A focused follow-up should remove only cache entries whose key class is defined by the released loader, at the same last-reference release point. It must not clear or replace the process-wide cache, because entries belonging to a running job or an ancestor loader must survive. Please include a regression test with two isolated child class loaders: releasing one must remove only its cache entries while retaining the other loader's entries. Then rerun the same 0/5/10-job experiment on a build from current `dev`, after a full GC, and publish the exact loader-count and Metaspace readings. That will show whether this remaining per-job root is gone without masking a live job's cache. -- 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]
