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

Reply via email to