RFR JDK-8162497 "Deadlock in obtainSendWindow"

ize is 16K. - connection send window is 64K-1. - each thread is trying to send more than 1 full size data frame. At this situation each thread captures and holds ~1K-3K portion of sending window, full sending window is exhausted and each sending thread is waiting (forever) to reach 16K. Thank you, Sergey Kuksenko.

Re: RFR JDK-8161091 Incorrect Stream.FlowControl implementation allows to send DataFrame even when window size was exhausted

Who could sponsor this? On 07/14/2016 07:53 AM, Chris Hegarty wrote: On 11 Jul 2016, at 23:47, Sergey Kuksenko wrote: I am awfully sorry, previous fix was incorrect. Please, review the right version: http://cr.openjdk.java.net/~skuksenko/jep110/8161091/webrev.01/ Looks good. Thanks Sergey

Re: RFR JDK-8161091 Incorrect Stream.FlowControl implementation allows to send DataFrame even when window size was exhausted

I am awfully sorry, previous fix was incorrect. Please, review the right version: http://cr.openjdk.java.net/~skuksenko/jep110/8161091/webrev.01/ On 07/08/2016 02:40 PM, Sergey Kuksenko wrote: Hi, Could you please review the following fix for JDK-8161091? http://cr.openjdk.java.net

RFR JDK-8161091 Incorrect Stream.FlowControl implementation allows to send DataFrame even when window size was exhausted

rmits. That means that client may send any amount of data if data frame size less than window size. Thank you, Sergey Kuksenko.

RFR JDK-8161004 "Bulk sending WindowUpdate frame speedup HTTP/2 performance up to 18x times and improve scalability"

3. WindowUpdate frame goes directly to HttpConnection bypassing Http2Connection.sendlock. That is allowed with proper protection for "do not insert WindowUpdate frame between Headers and Continuation frames". Thank you, Sergey Kuksenko.

Re: RFR JDK-8158980: Memory leak in HTTP2Connection.streams

Please, do this. On 06/20/2016 10:17 PM, Chris Hegarty wrote: On 20 Jun 2016, at 21:24, Sergey Kuksenko wrote: Hi, Could you please review the following fix for JDK-8158980? http://cr.openjdk.java.net/~skuksenko/jep110/8158980/webrev.00/ This looks good to me Sergey. I can sponsor it for

RFR JDK-8158980: Memory leak in HTTP2Connection.streams

Hi, Could you please review the following fix for JDK-8158980? http://cr.openjdk.java.net/~skuksenko/jep110/8158980/webrev.00/ Fix solves the following issue: https://bugs.openjdk.java.net/browse/JDK-8158980 Stream will be never deleted from HTTP2Connection.streams in the following condition

RFR JDK-8158980: Memory leak in HTTP2Connection.streams

Hi, Could you please review the following fix for JDK-8158980? http://cr.openjdk.java.net/~skuksenko/jep110/8158980/webrev.00/ Fix solves the following issue: https://bugs.openjdk.java.net/browse/JDK-8158980 Stream will be never deleted from HTTP2Connection.streams in the following condition

RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"

Hi, Could you please review the following fix for JDK-8158690? http://cr.openjdk.java.net/~skuksenko/jep110/8158690/webrev.00/ Fix solves the following issue: https://bugs.openjdk.java.net/browse/JDK-8158690