I don't think using AdvancedTlsX509KeyManager with OpenSslCachingKeyMaterialProvider is all that good an approach with this, because it essentially leaks all prior keys in memory. If the life of the process after a year has 5 versions, that's not that big of a deal. But if it changes ever hour, that's not good. I don't think we're going to put random detection code in AdvancedTlsX509KeyManager to just warn you that things have gone wrong either.

I don't think using AdvancedTlsX509KeyManager with OpenSslCachingKeyMaterialProvider is all that good an approach with this, because it essentially leaks all prior keys in memory. If the life of the process after a year has 5 versions, that's not that big of a deal. But if it changes ever hour, that's not good. I don't think we're going to put random detection code in AdvancedTlsX509KeyManager to just warn you that things have gone wrong either.

Yes, I think it should be used with caution.
In our case, the PKI-issued certificates have a relatively long lifetime, so over the application process’s three-month lifecycle, reloads occur only a few times.
To support users who require more frequent key rotation, Netty's OpenSslCachingKeyMaterialProvider would need to remove old keys.

As for AdvancedTlsX509KeyManager itself, I think we still need to handle alias changes?

As for AdvancedTlsX509KeyManager itself, I think we still need to handle alias changes?

Yes, that's tracked by #12485 . This PR doesn't actually address that, as it ignores the alias being used. I imagined keeping one older version around to handle in-progress handshakes. Since you're talking about every configuration having its own alias name, if the key manager mutates faster than handshakes complete (such that the alias is really old) then we could trigger an error in some way.

In our case, the PKI-issued certificates have a relatively long lifetime, so over the application process’s three-month lifecycle, reloads occur only a few times.

Okay. I'm fine with using a new alias each mutation in this key manager, but that should be consistent; for example, getPrivateKey() shouldn't return the new key when passed the old alias. That applies equally to all methods that receive the alias.

And we won't have the "this sure seems like a lot of mutations" warning.

At that point, if someone so desires they can improve OpenSslCachingKeyMaterialProvider to become an LRU cache (or introduce a new class). Then you could use a cache size of two.

As for AdvancedTlsX509KeyManager itself, I think we still need to handle alias changes?

Yes, that's tracked by #12485 . This PR doesn't actually address that, as it ignores the alias being used. I imagined keeping one older version around to handle in-progress handshakes. Since you're talking about every configuration having its own alias name, if the key manager mutates faster than handshakes complete (such that the alias is really old) then we could trigger an error in some way.

In our case, the PKI-issued certificates have a relatively long lifetime, so over the application process’s three-month lifecycle, reloads occur only a few times.

Okay. I'm fine with using a new alias each mutation in this key manager, but that should be consistent; for example, getPrivateKey() shouldn't return the new key when passed the old alias. That applies equally to all methods that receive the alias.

And we won't have the "this sure seems like a lot of mutations" warning.

At that point, if someone so desires they can improve OpenSslCachingKeyMaterialProvider to become an LRU cache (or introduce a new class). Then you could use a cache size of two.

I think the idea of "keeping one older version around" makes sense.
Updated the change to keep the previous one. Previous keyinfo can be accessed using the previous alias.
While the method chooseClientAlias will always return "current".

Also removed the warning part.
Will directly rely on the OpenSslCachingKeyMaterialProvider PR for the cache eviction support.

Thank you!