Unexpected javax.net.ssl.SSLHandshakeException in seemingly simple usage scenario with Jersey Client 2 (>= 2.41) #5647
Comments
|
Captured also list of client connections with netstat: |
sergiy-kozak
changed the title
|
This sounds like a problem with the certificate, or the SSL version. The JDK 21 release notes says:
|
|
The issue happens during the SSL connection handshake, there could be some difference between the server and client settings. You can use |
|
I have the impression that the error I get from running the program is just part of a bigger issue. I'm more worried what I observe about open connections by the process. Also note, clearly this has little to do with JDK itself, issue starts manifesting when changing Jersey libraries from |
|
For Jersey 2.43 when I enabled With Jersey 2.40 this doesn't happen. For program one connection is open and reused for consequent requests execution, protocol negotiation occurs once before first request as expected. Is there anything changed in connections management with HttpUrlConnection after 2.40? Why would every time to make a request the new connection is needed, is that anticipated by the implementation for e.g. pooling? |
|
There was quite some changes around SSL configuration and HttpUrlConnector happening in this commit: 73bdf5f |
KeepAlive caching of connections seems to be broken from 2.41 on. This would explain what you observe. See this ticket for details: |
Yes, that explains, thanks for linking it here. Currently forced to use old version, as Jersey client as of 2.41 is effectively broken. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using Jersey Client 2.41-2.43, I have tried to execute the following sample program with openjdk 21 to figure out other issues encountered in the real application.
The program fails to reach the end of requests loop:
During the above program execution, there is unexplainable lots of connections open by the process (obviously managed in some ways by client):
However, when switching to Jersey 2.40 that issue is not anymore. All requests are completed in expected normal way, and for program's java process only 2 sockets are kept open (and I assume just reused) through the entire run.
System:
Is this a regression of some kind? The same might be applicable for latest 3.x, but I cannot test it right ahead. For real application I will roll back to 2.40 as latest working one; in real application running in Debian 12 environment other exception is thrown,
javax.ws.rs.ProcessingException: java.net.SocketTimeoutException: Connect timed outwhile observing the same pattern of TCP connections usage.Update:
Jackson dependencies version used 2.17.0 (if relevant).
The artifact
com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-providerwas present on the classpath when running program with the above observations. When using 2.43 Jersey and removingjackson-jaxrs-json-providerfrom classpath makes program reach the end of the requests loop, however the usage of TCP connection shows same pattern. Also, there is major difference in the execution time (reproduced fairly consistent):The text was updated successfully, but these errors were encountered: