We are receiving a SSL handshaking exception when another part of the code is calling SSLContext.getInstance(). Can someone please confirm or deny the ability to have multiple concurrent SSLContexts running in the same JVM using the same provider? The method name getInstance implies a singleton.
Yes, you can have multiple SSLContext
instances, configured differently if you wish.
getInstance(...)
is generally part of the factory pattern, not the singleton pattern, although a number of implementations of the singleton pattern also use the factory pattern to access this singleton.
In addition, SSLContext.getInstance()
doesn't exist, only getInstance(String)
, getInstance(String,String)
or getInstance(String,Provider)
(and having an argument on the getInstance
method hardly makes sense for a singleton).
(Don't confuse this with SSLContext.getDefault()
, which will always return the current default instance, although this can also be changed globally with setDefault(SSLContext)
.)
Just in case you were talking about SSLContext.getDefault()
instead, it's worth noting that the default SSLContext
will only read and use the javax.net.ssl.*
system properties once, the first time it is loaded. This could have consequences if you set these properties somewhere within the code, but not somewhere else (or differently) and call SSLContext.getDefault()
in a different order: the first call to SSLContext.getDefault()
wins (assuming you're not complicating this with further calls to SSLContext.setDefault(...)
).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With