NETCONF-1006 has split the API and implementation of NetconfKeystoreAdapter. Looking at the reference implementation, there is a metric ton of implementation we can make.

Since this class lies in the critical path for establishing NETCONF device connections, we need to heavily favour the read path (i.e. the device connecting) vs. the update path (i.e. the configuration changing).

The first, and foremost, highlighted by NETCONF-1006 which uses as single instance, is the fact internal state uses Collections.synchronizedMap() – which means that all concurrent accesses get synchronized on three locks. This is quite wasteful, as the maps are typically not being modified. This needs to be solved by encapsulating internal state into an immutable object which is accessed in the read path. The update path updates this object in an atomic manner – i.e. it builds up the new state and propagates it via a volatile update. Since we have Java 11+, this really means we should use Java 9 Memory Model getAcquire/setRelease semantics to minimize global serialization.

The second set of improvements is in getJavaKeyStore(), which impacts SslHandlerFactoryImpl – which is a number of things:

Here the update path should filter private keys which do not have a certificate chain, so that we can safely use requireCertificateChain() and get rid of a source of exceptions.

Also, getCertificateChain() should do its best to avoid the call to CertificateFactory.getInstance("X.509") and reuse a single factory if it is known to be thread-safe. Otherwise we should degrate to something which is reasonable (given we know there is a Netty thread pool servicing these requests).

Next up there is getJavaPrivateKey(), which guesses what factory to use, trying RSA and DSA, each time acquiring KeyFactory.getInstance(). At the end of the day we should be smart about these and probably make the decision in the configuration update path to bind the proper factory – and share it if it is thread-safe.

And finally, there is KeyStore.getInstance() calls with "JKS". The question here is two-fold: can we use a better keystore and can we manage instantiation better given that we really are providing an immutable view, which is populated with well-known values?