Race condition

[dtbaum]

Fixed race condition, see:
#5358

[jansupol]

@dtbaum Can you please elaborate on how the race condition happens?

[dtbaum]

@jansupol The race condition occurs when multiple independent Jersey client instances, running in parallel threads, make a GET request.

When the first GET request is in progress, all parallel requests from other Jersey clients (other client instances, but same SSLContext and same target), in other threads, fail with SSLHandshakeException: PKIX path building failed.
The first caller uses the correct trust store (which is defined in used SSLContext), the parallel callers use the java default trusstore.. The problem is not working if (DEFAULT_SSL_SOCKET_FACTORY.get() == suc.getSSLSocketFactory()) condition. For subsequent requests it returns suc.getSSLSocketFactory() default factory, BUT another object reference to default factory, therefore the reference equality doesn't work here. A deep equality check, like working .equals() or removing the condition would solve it.
Once the first GET request is completed, all subsequent requests work without error.
Here is the code which demonstrates this issue:
https://github.com/dtbaum/jersey-bug-report

If you get any issues getting the example to run, please let me know. I would add it as a broken JUnit test on this jersey branch.

[dtbaum]

@jansupol: Did you succeed in reproducing the problem?
The reason for the exception is following: Due to mentioned reference equality check, the "parallel" threads do not use the specified SSLContext, but the default SSLContext instead.
Consequently, the server certificate validation occurs not against the specified truststore, but against the default truststore, leading to the mentioned exception.

[jansupol]

Thank you for the reproducer @dtbaum. The fix breaks SslHttpUrlConnectorTest.testSSLWithCustomSocketFactory, but we'll check if there is any possible fix for it.

[jansupol]

Related #4815

This bug has a long history. Basically, there is a bug in JDK that we try to workaround, but there seem to be multiple requirements that go against each other.

[dtbaum]

@jansupol: As much as I understand (which isn't much :-) ) a deep, reliable equality check, like working .equals() instead of object reference equality, would help, without violating other requirements?

[dtbaum]

@jansupol: I think, I have a fix for the race condition, without violating #4757/#4566.
I have made the method HttpUrlConnectorProvider.ConnectionFactory.getConnection() thread-safe:
This ensures that parallel initialization in the HttpsURLConnection.getDefaultSSLSocketFactory() is avoided.
See the screenshot below for call hierarchy: