Thanks for the feedback, Steve Loughran.
is there any reason not to use a RetryPolicy here
Good question! The reason is the following:
First of all, we definitely want exponential backoff, to prevent us causing ddos on kdc.
In RetryPolicies, there is no RetryUpToMaxmumTimeWithProportinalSleep, and IMO the reason lacking one there, is it's not feasible/maintainable to calculate a maxRetries inline when invoking the base class ctor. It's eventually calculating a taylor series IIUC.
In our case, we could calculate the maxRetries beforehand, then initialize a retryUpToMaximumCountWithProportionalSleep accordingly. That ends up in similar code to getNextTgtRenewalTime in the caller. Moreover, personally I feel the last retry before expiry could be helpful, otherwise the backoff will likely miss the end time.
Test can probably import org.apache.hadoop.conf.Configuration rather than declare variables that way.
Not really, there's a conflict with javax.security.auth.login.Configration. On a second thought I switched the two to make hadoop's Configuration the default.
Other comments are addressed in patch 7.
Regarding the test, having a real test is brittle and a bit time consuming (due to TICKET_RENEW_WINDOW), but having a fake test as Kai Zheng pointed out is.... fake. I don't have a strong option, but if it ends up spamming pre-commit, we may switch to the mock test after all.