DanielLeens commented on issue #12456: URL: https://github.com/apache/seatunnel/issues/12456#issuecomment-5814905155
Classification: A / Zeta class-loader lifecycle and Metaspace.\n\nThank you — the new observations materially narrow the investigation. With cache mode disabled, current dev keys DefaultClassLoaderService by job ID and creates a SeaTunnelChildFirstClassLoader for each unseen JAR set; it only removes that entry when releaseClassLoader reaches a zero reference count and clears matching thread context class loaders. The six-to-one INFORMATION_SCHEMA-style ambiguity is not present here: the growing ChildFirst loader count after forced GC means we now need to determine whether releases are not reached, a reference survives release, or new loaders are still being created during the observation window.\n\nChanging classloader-cache-mode to true is a useful mitigation because equal JAR sets share the cache, but it is not yet proof of the retaining path. Please keep monitoring it and do not treat it as a root-cause fix.\n\nFor the next evidence set, please provide sanitized, time-aligned snapshots from one affected worker: (1) running job IDs plus ChildFirst loader count and loaded-class total before and after several sequential submissions or restarts; (2) the matching Create classloader and Release classloader log lines for one representative job; and (3) the MAT path-to-GC-roots for two retained ChildFirst loaders, including the owning job/JAR key if visible. A short MongoDB-to-Hive reproduction with cache mode false, followed by a clean job termination, would be especially useful.\n\nI also found open #10678, which proposes an opt-in deep-clean path. Please do not enable or merge it as a blanket workaround for this report: its own description says explicit close is unsafe as the default until residual TCCL/static references are proven safe. The evidence above should decide whether that lifecycle work is relevant here. Keep host names, credentials, keytabs, and full production configuration redacted. -- 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]
