slfan1989 commented on PR #5443:
URL: https://github.com/apache/hadoop/pull/5443#issuecomment-1451394954
> Yes. By in memory variables I meant the class instance variables like
currentTokens, currentKey, allKeys, etc. Even though SQLFederationStateStore
throws an exception, all the current methods in
RouterDelegationTokenSecretManager catches these exceptions and either returns
or terminates the app rather than throwing it back & handling appropriately
For the client, the RM is blocked. For the client, the Router is the RM.
When implementing this function, we should be close to the realization of the
RM. I think Router's implementation is reasonable.
RMDelegationTokenSecretManager#storeNewMasterKey
```
protected void storeNewMasterKey(DelegationKey newKey) {
try {
LOG.info("storing master key with keyID " + newKey.getKeyId());
rm.getRMContext().getStateStore().storeRMDTMasterKey(newKey);
} catch (Exception e) {
if (!shouldIgnoreException(e)) {
LOG.error(
"Error in storing master key with KeyID: " + newKey.getKeyId());
ExitUtil.terminate(1, e);
}
}
}
```
RouterDelegationTokenSecretManager#storeNewMasterKey
```
public void storeNewMasterKey(DelegationKey newKey) {
try {
federationFacade.storeNewMasterKey(newKey);
} catch (Exception e) {
if (!shouldIgnoreException(e)) {
LOG.error("Error in storing master key with KeyID: {}.",
newKey.getKeyId());
ExitUtil.terminate(1, e);
}
}
}
```
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]