On Thu, 25 May 2023 21:40:41 GMT, Daniel Fuchs <dfu...@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. > > Hi, thanks a lot for the bug report and the fix. > > The fix looks reasonable, however the test fails quite consistently in our CI > on many platform: > > > java.lang.RuntimeException: Too large intermediate buffer, server sent > 10x300000 bytes > at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1583) > > > I'm not sure I understand the logic of the test either. Does it depend on > some assumption about the size of the socket buffers? From where do the > various constants in the test come from? Also could there be a better > solution than `sleep(2000)` ? @dfuch, thanks for your lightning-fast reply. Indeed it relies on buffer sizes. The test works for me on Linux and Mac, but real life seems to be more diverse. Unfortunately, I don't know how else to reproduce the problem and test the fix - the tested logic is hidden deep. It may be possible to commit the fix without unit-test? The regression is not affected, and the behavior can be checked manually using the recipe from the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563562380