lcx412 commented on PR #29874: URL: https://github.com/apache/flink/pull/29874#issuecomment-6811934627
Thanks @gaborgsomogyi — you were right. `SecurityUtils.install` should stay unconditional, and my original explanation was not precise enough. I have since found the actual failure path, and it is independent of Paimon: a CICD application-mode job without Paimon reproduced the expiry. The refresh itself succeeded and produced a new token, but the long-lived `FileSystemJobResultStore` / checkpoint `DFSClient` continued using the startup token. The version-specific trigger appears to be `FLINK-27204` (1.19+): `FileSystemJobResultStore` I/O was moved onto the shared `cluster-io` executor, and `DefaultDelegationTokenManager` uses the same executor for periodic token refresh. Java thread-pool workers inherit the `AccessControlContext`/Subject of the thread that creates the first worker, so `UserGroupInformation.getCurrentUser()` in the receiver can differ from the UGI captured by the client. I verified this with a minimal JVM probe: a pool created under Subject A but first submitted under Subject B runs subsequent tasks under Subject B. The install-idempotency change is therefore not sufficient: the affected batch already showed `Security configuration is already installed` and no re-install, yet still failed at the 24h token deadline. I will keep this PR only as temporary reference for now and will not present it as the fix. I intend to come back with a focused PR that makes the delegation-token receiver/provider target the security-context/login UGI explicitly, with a regression test. Thanks for pushing back on the original approach. -- 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]
