On Thu, 25 May 2023 20:17:39 GMT, zhurs <d...@openjdk.org> wrote: > When using HttpClient to make requests to HTTPS resources, there is an issue > where the entire file is being downloaded into memory without the ability to > limit the buffer size. > If the SSLEngine cannot decode the entire buffer due to the algorithm's > blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW > status, which leads to SSLFlowDelegate.Reader requesting more data despite > the output queue being full.
The HttpClient supports properties that can be used to tune the SEND and RCV buffer sizes. I would not recommend to use them in production unless you absolutely know what you do, because setting them can prevent underlying OD optimizations which in turn can affect performance negatively. However - using them in tests is fair game. If you could explain the relationship between the constants in the test and the assumed socket buffer sizes (on the client size I assume) then we may try to experiment forcing the test's client to use some specific value for SNDBUF and RCVBUF, and see if that works. It may not, but maybe we could explore this possibility before ditching the test. If we notice that there are some platforms where the test always pass reliably we could also experiment with using `@requires` to restrict the test to run on these platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564006762
