SEZ9 commented on issue #12456: URL: https://github.com/apache/seatunnel/issues/12456#issuecomment-5882668611
@wangbing505 thanks for the Arthas snapshots, they are helpful. They show `SeaTunnelChildFirstClassLoader` instances appearing at submission (2 after the first job, 4 after the second, with `loadedCountTotal` roughly doubling) while the AppClassLoader stays essentially flat, which points at the per-job classloader lifecycle rather than the base worker footprint. Your comment appears to be cut off after "After another 10 minutes," — could you post the rest of that snapshot? The key question is whether the `numberOfInstances` count for `SeaTunnelChildFirstClassLoader` drops back after the jobs finish or stays at 4 and keeps growing with the hourly runs. What the snapshots don't yet tell us is *why* a loader survives: either the engine never released the classloader for that JAR set, or the release happened but something static or thread-bound still pins it. I'd rather not patch individual registries or change how Hadoop/Parquet classes are loaded until we know which of the two cases this is. To pin that down, could you provide one sanitized, time-aligned run from the affected worker with: 1. The classloader create/release log lines for each JAR key, plus the reference-count result after the finished job. 2. If you can take a heap dump, a MAT path-to-GC-roots for one `SeaTunnelChildFirstClassLoader` captured *after* that release. 3. A minimal repeated reproduction of the failing job with classloader cache mode disabled, so we can confirm it's independent of your production configs. @modelpath-dev to your question: raising the Metaspace limit would only delay the failure here, since the loader count grows per submission; the evidence so far is consistent with a leak rather than an undersized Metaspace. For wangbing505, enabling classloader cache mode is a reasonable mitigation while the jobs share the same JAR set, but it's not the root-cause fix. <!-- streview-comment:1395 --> -- 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]
