On 22/06/2020 16:39, Sebastian Stenzel wrote:
Certain users of my software run into problems with HttpClient.newHttpClient()
on JDK 14.0.1 and I don't feel like I can handle it properly without catching
Errors.
Calling said method fails when encountering Selector.open(), which in its
Windows-specific implementation relies on loopback-TCP connections. These
connections can, of course, be blocked by the OS or, as in the case of my user,
by some anti-malware tool.
I can't argue whether it is good or bad implementing the selector the way it is, however
I'm pretty sure that commenting exceptions being "unlikely" without further
explanation isn't exactly the best practice for this case:
https://github.com/openjdk/jdk/blob/5adfaa39866f3127000f0779158c65afe1d24007/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java#L309-L314
<https://github.com/openjdk/jdk/blob/5adfaa39866f3127000f0779158c65afe1d24007/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java#L309-L314>
Since my related bug report (JDK-8247996) was turned down (maybe the tester
forgot to or chose not to block the socket connection), I'd like to ask if it
is at least possible to document the fact that creating an HttpClient can have
the side effect of instantaneously creating a loopback connection. I would
prefer to even throw a checked exception, but this would break the API.
Happy to create a PR, but I'd like to do this the right way, therefore starting
this discussion.
The wakeup mechanism in the Selector implementation on Windows uses a
loopback connection. Something fishy in the configuration (or firewall
or VPN) if that is blocked. There is a proposal to replace this with a
Unix domain socket but that will only work on newer releases of Windows.
The HTTP client behavior to catch the IOException and throw
InternalError is currently tracked by JDK-8248006 [1].
-Alan
[1] https://bugs.openjdk.java.net/browse/JDK-8248006
