-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
22
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
JDK 21, JDK 22
Using MacOSX 14.2 (23C64)
A DESCRIPTION OF THE PROBLEM :
When running the below code, the call to `openStream` blocks when calling a website that does not return any payload if conditions are not met. Ironically, one such website is https://openjdk.org. Also, the call `submit. get (1, TimeUnit. SECONDS) ' is not respected either. Thus, this small application will be blocked until the timeout for `openStream` is triggered, ignoring any timeouts.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Take the code and run it in JDK 21 or 22. You will find that:
1. Calling new URI("https://openjdk.org/").toURL().openStream() will block
2. The `get` timeout in 29 is not respected even though the cap is specified to be 1 second
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If it is expected that `new URI("https://openjdk.org/").toURL().openStream()` will not resolve in time, then `submit.get(1, TimeUnit.SECONDS)` should timeout, and a `TimeoutException` should be thrown in 1 second.
ACTUAL -
Hangs, or if you are lucky, a `TimeoutException` will occur, but after many minutes
---------- BEGIN SOURCE ----------
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Either:
1. Take out the `ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor()` out of the TWR block
2. Don't call `openStream`, instead use `url.openConnection()`, set the connectTimeout to 1000, setReadTimeout to 1000, and set the requestProperty to ("User-Agent", "Mozilla/5.0");
FREQUENCY : always
JDK 21, JDK 22
Using MacOSX 14.2 (23C64)
A DESCRIPTION OF THE PROBLEM :
When running the below code, the call to `openStream` blocks when calling a website that does not return any payload if conditions are not met. Ironically, one such website is https://openjdk.org. Also, the call `submit. get (1, TimeUnit. SECONDS) ' is not respected either. Thus, this small application will be blocked until the timeout for `openStream` is triggered, ignoring any timeouts.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Take the code and run it in JDK 21 or 22. You will find that:
1. Calling new URI("https://openjdk.org/").toURL().openStream() will block
2. The `get` timeout in 29 is not respected even though the cap is specified to be 1 second
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If it is expected that `new URI("https://openjdk.org/").toURL().openStream()` will not resolve in time, then `submit.get(1, TimeUnit.SECONDS)` should timeout, and a `TimeoutException` should be thrown in 1 second.
ACTUAL -
Hangs, or if you are lucky, a `TimeoutException` will occur, but after many minutes
---------- BEGIN SOURCE ----------
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Either:
1. Take out the `ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor()` out of the TWR block
2. Don't call `openStream`, instead use `url.openConnection()`, set the connectTimeout to 1000, setReadTimeout to 1000, and set the requestProperty to ("User-Agent", "Mozilla/5.0");
FREQUENCY : always