Savonitar commented on code in PR #28639:
URL: https://github.com/apache/flink/pull/28639#discussion_r3537210614
##########
flink-runtime/src/main/java/org/apache/flink/runtime/resourcemanager/ResourceManager.java:
##########
@@ -427,6 +430,14 @@ public CompletableFuture<RegistrationResponse>
registerJobMaster(
jobMasterIdFuture,
(JobMasterGateway jobMasterGateway, JobMasterId
leadingJobMasterId) -> {
if (Objects.equals(leadingJobMasterId,
jobMasterId)) {
+ // Register with the delegation token
manager first; a
+ // provider failure rejects this
registration so the job
+ // never starts without the tokens it
requires.
+ try {
+
delegationTokenManager.registerJob(jobId, jobConfiguration);
+ } catch (Exception e) {
+ return new
RegistrationResponse.Failure(e);
+ }
Review Comment:
> time windows from job perspective where no crentials exist
Yes, it is accepted by design. A job registering during it has no tokens
yet, so its connector auth fails and the standard restart strategy brings it
back once the tokens arrive. Short-lived jobs can set
`security.delegation.tokens.reobtain.cooldown` to 0.
On the IO pressure point, agreed. The obtain cycle runs on the shared
cluster-io pool and nothing bounds its queue wait, so under pressure the window
just widens. The periodic renewal uses the same pool, so it slides by the same
amount. The FLIP calls this out as a starvation and keeps it as-is
deliberately.
The one guarantee is that it only brings the next cycle forward and never
pushes an already scheduled renewal later. Survival is the restart path either
way.
--
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]
