On 21/08/2021 08:17, Jaikiran Pai wrote:
JEP-353[1] which got implemented and released in JDK13, states:
"The java.net package defines many sub-classes of SocketException. The
new implementation will attempt to throw the same specific
SocketException as the old implementation but there may be cases where
they are not the same."
In one of the projects I watch, a recent issue[2] shows that the
"Socket.connect(...)" call, in certain cases, now throws a
"java.net.NoRouteToHostException" exception as opposed to
"java.net.ConnectException" in previous versions before this change.
The "Socket.connect(...)" javadoc states that this API can throw an
"IOException", so this change, in theory, is still fine and doesn't
break any API contract. However, as noted in [2], certain libraries
(Apache HTTP client 4.5.x versions in this case) expect a certain
exception type when it's dealing with decision making for HTTP request
retries. Due to this change in the exception type being thrown, the
Apache HTTP client library now behaves differently in Java 11 and Java
16.
Is this change of exception type being thrown intentional? Or is there
interest in changing back to the previous exception type to preserve
backward compatibility? If not, I think the Apache HTTP client library
will have to perhaps do certain changes to have this part of the code
behave the same across Java versions.
Thanks for the mail, I haven't seen any other reports on this.
Can you say which operating system and say a bit more about the
conditions where this is observed? When connecting to a host that is not
reachable then it's possible for the underlying connect to fail with a
"Connection timed out", "No route to host", or other errors.
The reason I'm asking about the OS/conditions is that the old
implementation did attempt to map specific errors to
NoRouteToHostException. There's an example stack stack (Windows, with
JDK 9) in this bug report:
https://bugs.openjdk.java.net/browse/JDK-8042714
In general, the mapping of connect errors to sub-classes of
SocketException has always been best effort and I both both
ConnectException and NoRouteToHostException are possible, all depends on
the underlying error.
So my initial reaction is that we shouldn't do anything right now, I
think we need to know a bit more abut the environment/conditions as I'm
puzzled as to why the HTTP client retry decision didn't run into this
before with the old implementation.
-Alan
