DanielLeens commented on issue #11584: URL: https://github.com/apache/seatunnel/issues/11584#issuecomment-5111114514
Thanks for the detailed report. I checked the current Kudu source path, and this looks like a real lifecycle bug rather than only an E2E flake. The reader currently creates a `KuduScanner` from each split token inside `KuduSourceReader.pollNext(...)`, but that scanner is not closed in a `finally` / try-with-resources path. Separately, `KuduInputFormat.closeInputFormat()` closes the shared `KuduClient`, but that only happens at reader close time and does not release each per-split scanner as soon as the split is consumed. The enumerator also keeps its own `KuduInputFormat` / client until enumerator close after scan-token generation. A focused PR should probably keep the fix narrow: 1. close each `KuduScanner` after the split is consumed, including exceptional paths; 2. release the enumerator-side Kudu client as soon as split discovery no longer needs it, or make the current enumerator close ordering explicit if it must stay open; 3. make reader-side `KuduClient` shutdown wait for Kudu's async resources to be fully terminated before the connector classloader can be released, if the Kudu client API exposes a safe way to do that; 4. add regression coverage that fails if repeated Kudu E2E jobs leave `kudu-nio-*` cleanup threads running after the connector classloader is gone. So I agree this should be tracked as a connector resource-cleanup bug, with the first PR centered on deterministic scanner/client shutdown rather than broad E2E retries. -- 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]
