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

Reply via email to