SEZ9 commented on issue #12456: URL: https://github.com/apache/seatunnel/issues/12456#issuecomment-6137262379
@wangbing505 thanks for the 0/5/10-job comparison and for walking the Path to GC Roots for each of the 20 `SeaTunnelChildFirstClassLoader` instances. The repeated path you posted is the key piece: the shaded `SnappyCodec` class, defined by a released connector loader, is still held as a key in a process-wide `ConcurrentHashMap` (Hadoop `ReflectionUtils.CONSTRUCTOR_CACHE`), which pins the whole loader and its Metaspace. To keep the scope honest about what is already in `dev` (`4ae4fee30165e9f082f80b05ec5a8f3bb810b474`): the two cleanup commits for this issue, `35b9d5e26d2` and `097101c21be`, clear the MongoDB pruner, `WritableComparator`, and the four `CodecPool` registries when the last reference to a non-cached job loader is released. They do not touch `ReflectionUtils.CONSTRUCTOR_CACHE`, so the root you found is not covered and #12456 cannot be treated as resolved yet. #12626 remains a partial fix. Concrete asks for the follow-up: 1. Extend the existing last-reference release path so it removes only `CONSTRUCTOR_CACHE` entries whose key class was defined by the loader being released. Please do not clear or swap the whole static map — entries belonging to running jobs or ancestor loaders must survive. 2. Add a regression test with two isolated child class loaders: releasing one must drop only its own cache entries while the other loader's entries remain present. 3. Rebuild from current `dev` with that change, rerun the same 0/5/10-job experiment, trigger a full GC before each reading, and post the exact `SeaTunnelChildFirstClassLoader` counts and Metaspace numbers. If any loader is still retained, please attach its Path to GC Roots the same way you did here. That will tell us whether this remaining per-job root is gone without masking a live job's cache. <!-- streview-comment:1713 --> -- 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]
