Hi,
Please find below a fix for:
8217264: HttpClient: Blocking operations in mapper function do not
work as documented
[1] https://bugs.openjdk.java.net/browse/JDK-8217264
webrev:
[2] http://cr.openjdk.java.net/~dfuchs/webrev_8217264/webrev.00/
The issue here is that if you try to map an InputStream to a
GZIPInputStream in a mapper function provided to
BodySubscribers::mapping, the response will be wedged.
This is because the constructor of GZIPInputStream calls
InputStream::read which blocks the current thread.
The fix is to ensure that a new executor task will be used when
calling BodySubscriber::getBody - which is the point at which the
mapping function gets executed, in order to avoid blocking the
current task.
This is not a completely satisfactory solution, as doing
blocking operations in a mapper function will take a thread
out of the Executor's pool until the blocking operation
eventually succeeds - which might be until the last byte
of the response is received (or worse?), and might end
up starving the HttpClient of available threads.
I believe the documentation of BodySubscribers::mapping
should instead promote safer behaviour - and steer users
out of executing blocking operations in the mapper function.
I have logged [3] JDK-8217627 to that effect.
Even if we fix the API documentation as in [3] - and discourage
blocking operation in the mapper, I still believe we should
support the occasional blocking mapper functions (with the
understanding that the response might get wedged if client's executor
doesn't have sufficient free threads) - if only to allow mapping
from InputStream to GZIPInputStream when the Executor is a sufficiently
sized thread pool executor. This is the effect of my proposed fix [2].
best regards,
-- daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8217264
[2] http://cr.openjdk.java.net/~dfuchs/webrev_8217264/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8217627
