Re: RFR JDK-8158980: Memory leak in HTTP2Connection.streams
Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bae5b550b829 -Chris. > On 22 Jun 2016, at 22:17, Sergey Kuksenko wrote: > > 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 you. >> >> -Chris. >
Re: RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"
Sergey and I discuss this off-line and the potential performance improvement here is very significant; raises performance from 25 request/sec to 6000 requests/sec in one particular test. I think we should proceed with this change, unless there are strong objections. We can revisit this later, if necessary. And/Or make implementation changes if issues arise from this. -Chris. > On 21 Jun 2016, at 06:56, Chris Hegarty wrote: > > On 20 Jun 2016, at 21:36, Sergey Kuksenko wrote: >> >> 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 > > Hmmm….. I’m not sure that disabling Nagle is the right thing to do, > at least not without doing further investigation about the size / chunks > of data that can be sent. Though I do note that the old > HtpURLConnection implementation does set setTcpNoDelay(true), > while buffering the data to be written. > > -Chris.
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Hi Roger,
Thanks for having a look at this!
> On 22 Jun 2016, at 18:03, Roger Riggs wrote:
>
> Hi Pavel,
>
> in general, this treatment is fine, some comments below,
>
>> * When a Close message has been received, the WebSocket Protocol
>> * mandates it is handled in a certain way.
> 'a certain way' seems odd in a specification. Instead, perhaps refer to the
> RFC as you have cited below,
> perhaps just move the reference up.
>
> https://tools.ietf.org/html/rfc6455#section-5.5.1";>Close
> * and
> * https://tools.ietf.org/html/rfc6455#section-7.4";>Status Codes.
I agree.
>> *
>> * After a Close message has been received, the {@code WebSocket}
>> * will close automatically.However, the client may finish sending the
> "will be closed at the earliest of..."
I have had second thoughts on this paragraph. The thing is the current wording
precludes a use case which in my opinion we should allow. Namely, we should
allow the client to send their own Close message.
CompletionStage onClose(WebSocket webSocket, int statusCode, String reason) {
webSocket.sendClose(1000, "last_sent_id=...");
return null;
}
As I understand the reason string was designed for things likes this, a final
piece of information an endpoint believes the other should have.
The spec is pretty vague in this area:
...If an endpoint receives a Close frame and did not previously send a
Close frame, the endpoint MUST send a Close frame in response. (When
sending a Close frame in response, the endpoint typically echos the
status code it received.) It SHOULD do so as soon as practical. An
endpoint MAY delay sending a Close frame until its current message is
sent (for instance, if the majority of a fragmented message is
already sent, an endpoint MAY send the remaining fragments before
sending a Close frame)...
To me it sounds like:
1. We should send the same code unless there's a reason not to (and that's what
the default implementation does)
2. We are allowed (naturally) to send any reason with it
Summing up, I would propose to change the whole paragraph to this:
* After a Close message has been received, the {@code WebSocket}
* will close automatically. However, the client may finish
* sending the current sequence of message parts, if any. To facilitate
* this, the {@code WebSocket} will close after the completion of the
* returned {@code CompletionStage} or earlier if a Close message has
* been sent.
I think the behaviour of the WebSocket in case the client tries to start a new
messages sequence from within onClose (if the previous one has been finished) is
implementation specific. It might report to onError, or send a Close message
automatically or both. What's important is that the server SHOULD NOT receive
any part of the new message.
>> * The {@code statusCode} is an integer in the range {@code 1000 <= code
>> * <= 4999}, except for {@code 1004}, {@code 1005}, {@code 1006} and {@code
>> * 1015}*and some others *that can be only set by the {@code WebSocket}.
> "and some others" is too vague for a specification. It should be possible to
> test every possible value
> as being allowed, indeterminate, or illegal.
Okay. Fair enough. The thing is the interpretation of the list of standard
status codes and their semantics is a bit opinionated. I tried to avoid rigidity
here. On the other hand maybe we could define what is 100% prohibited and 100%
acceptable? Like a black and a white lists. In this case we will have a bit more
freedom later.
What would you say about this?
* The {@code statusCode} is an integer in the range {@code 1000 <= code
* <= 4999}.
...
* @implSpec The implementation is required to reject the following codes:
*
*
* {@code 1004}, {@code 1005}, {@code 1006} and {@code 1015}.
*
*
* At the same time the following codes are accepted:
*
*
* {@code 1000}, {@code 1001} and {@code 1008}.
*
*
* Accepting or rejecting other codes is implementation specific.
*
* @implNote This implementation rejects the following codes (in addition to
* those rejected by default):
*
*
* {@code 1002}, {@code 1007}, {@code 1010} and {@code 1011}.
*
*
Thanks,
-Pavel
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Hi,
On Thu, Jun 23, 2016 at 2:19 PM, Pavel Rappo wrote:
> Summing up, I would propose to change the whole paragraph to this:
>
> * After a Close message has been received, the {@code WebSocket}
> * will close automatically.
I would remove this. It is clear from the text below *when* the
implementation will send the reply close frame.
> However, the client may finish
> * sending the current sequence of message parts, if any.
I think you should not use the word "client" since it's not clear if
you refer to the application or the implementation.
Here it can be mistaken for both, but it's really the implementation.
However, the readers of the Javadocs will mostly be application
writers and would interpret it as the application.
> To facilitate this,
Remove it: "facilitation" is an implementation detail.
> the {@code WebSocket} will close after the completion of the
> * returned {@code CompletionStage} or earlier if a Close message has
> * been sent.
I would add:
"The implementation will take care of sending the reply close frame to
the server and close the underlying TCP connection.
Applications _may_ explicitly invoke sendClose() if they want to send
a different code or reason in the reply close frame."
> I think the behaviour of the WebSocket in case the client tries to start a new
> messages sequence from within onClose (if the previous one has been finished)
> is
> implementation specific. It might report to onError, or send a Close message
> automatically or both. What's important is that the server SHOULD NOT receive
> any part of the new message.
I think this is wrong.
Leaving room to "implementation specific" details is allowing for
writing applications that are not portable.
WebSocket's close mechanism is a double half close, like TCP.
In TCP the semantic is very clear: sideA can half close, sideB can
continue sending data, sideA will continue reading data, until sideB
half closes.
Same semantic in WebSocket.
WebSocket's onClose() is invoked when the server has half closed,
similar to reading -1 from TCP.
That only means that the server will not send more data.
The client side could send data, and the server must receive it
without problems.
Once the client decides it's finished sending data, it will return
from onClose(), and the implementation will send the reply close frame
(if not already sent by the application).
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
> On 23 Jun 2016, at 14:48, Simone Bordet wrote: > > ... > > WebSocket's close mechanism is a double half close, like TCP. > In TCP the semantic is very clear: sideA can half close, sideB can > continue sending data, sideA will continue reading data, until sideB > half closes. > Same semantic in WebSocket. At one point I thought the same, but after, yet another, re-reading of the RFC I disagree. The semantics are somewhat stronger in WebSocket, albeit that the wording is a little squirrely : 5.5.1 Close [1] It SHOULD do so as soon as practical. An endpoint MAY delay sending a Close frame until its current message is sent (for instance, if the majority of a fragmented message is already sent, an endpoint MAY send the remaining fragments before sending a Close frame). -Chris. [1] https://tools.ietf.org/html/rfc6455#section-5.5.1
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Simone,
> On 23 Jun 2016, at 14:48, Simone Bordet wrote:
>
> I think you should not use the word "client" since it's not clear if
> you refer to the application or the implementation.
> Here it can be mistaken for both, but it's really the implementation.
> However, the readers of the Javadocs will mostly be application
> writers and would interpret it as the application.
Is this some kind of a clever sarcasm, designed to point out the ambiguity in
question? Because I actually meant the *application*. Consider the following
flow of events (let's assume a simplified scenario where all CFs from sendText
are returned already completed):
|->sendText("...", false);
|->sendText("...", false);
|<-onClose()
|->sendText("...", false); (A)
|->sendText("...", true); (B)
onClose() has been received, but the application can still send messages until
the last chunk has been finally sent. Do you agree with this?
> I think this is wrong.
> Leaving room to "implementation specific" details is allowing for
> writing applications that are not portable.
We're talking about an extremely rare corner case, where we guarantee that a new
message WILL NOT be sent to the server. The difference is how the WebSocket will
react on attempting to do so.
Okay, I'm fine with REQUIRING is a new message is a attempted to be send, WS
will send a Close message instead and complete the CF returned from send
operation exceptionally.
> WebSocket's close mechanism is a double half close, like TCP.
> In TCP the semantic is very clear: sideA can half close, sideB can
> continue sending data, sideA will continue reading data, until sideB
> half closes.
> Same semantic in WebSocket.
>
> WebSocket's onClose() is invoked when the server has half closed,
> similar to reading -1 from TCP.
> That only means that the server will not send more data.
> The client side could send data, and the server must receive it
> without problems.
> Once the client decides it's finished sending data, it will return
> from onClose(), and the implementation will send the reply close frame
> (if not already sent by the application).
I'm not a TCP expert. Does TCP allow an endpoint to skip the data it receives
after this endpoint has half-closed the connection? Because WebSocket does:
...However, there is no guarantee that the
endpoint that has already sent a Close frame will continue to process
data...
Thanks,
-Pavel
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Hi Pavel,
I would avoid terms like application and client in any specification or
API description,
it may be that the caller of the API is another library.
The javadoc should focus on the behavior of each method when it is called.
$.02, Roger
On 6/23/2016 10:09 AM, Pavel Rappo wrote:
Simone,
On 23 Jun 2016, at 14:48, Simone Bordet wrote:
I think you should not use the word "client" since it's not clear if
you refer to the application or the implementation.
Here it can be mistaken for both, but it's really the implementation.
However, the readers of the Javadocs will mostly be application
writers and would interpret it as the application.
Is this some kind of a clever sarcasm, designed to point out the ambiguity in
question? Because I actually meant the *application*. Consider the following
flow of events (let's assume a simplified scenario where all CFs from sendText
are returned already completed):
|->sendText("...", false);
|->sendText("...", false);
|<-onClose()
|->sendText("...", false); (A)
|->sendText("...", true); (B)
onClose() has been received, but the application can still send messages until
the last chunk has been finally sent. Do you agree with this?
I think this is wrong.
Leaving room to "implementation specific" details is allowing for
writing applications that are not portable.
We're talking about an extremely rare corner case, where we guarantee that a new
message WILL NOT be sent to the server. The difference is how the WebSocket will
react on attempting to do so.
Okay, I'm fine with REQUIRING is a new message is a attempted to be send, WS
will send a Close message instead and complete the CF returned from send
operation exceptionally.
WebSocket's close mechanism is a double half close, like TCP.
In TCP the semantic is very clear: sideA can half close, sideB can
continue sending data, sideA will continue reading data, until sideB
half closes.
Same semantic in WebSocket.
WebSocket's onClose() is invoked when the server has half closed,
similar to reading -1 from TCP.
That only means that the server will not send more data.
The client side could send data, and the server must receive it
without problems.
Once the client decides it's finished sending data, it will return
from onClose(), and the implementation will send the reply close frame
(if not already sent by the application).
I'm not a TCP expert. Does TCP allow an endpoint to skip the data it receives
after this endpoint has half-closed the connection? Because WebSocket does:
...However, there is no guarantee that the
endpoint that has already sent a Close frame will continue to process
data...
Thanks,
-Pavel
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Hi, On Thu, Jun 23, 2016 at 3:58 PM, Chris Hegarty wrote: > At one point I thought the same, but after, yet another, re-reading of the RFC > I disagree. The semantics are somewhat stronger in WebSocket, albeit that > the wording is a little squirrely : > > 5.5.1 Close [1] > >It SHOULD do so as soon as practical. An >endpoint MAY delay sending a Close frame until its current message is >sent (for instance, if the majority of a fragmented message is >already sent, an endpoint MAY send the remaining fragments before >sending a Close frame). And the disagreement is that TCP can send an unlimited amount of data in half closed state, while WebSocket *seems* to hint that it *may* send a *non specified* amount of fragments ? :) -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
> On 23 Jun 2016, at 15:36, Simone Bordet wrote: > > Hi, > > On Thu, Jun 23, 2016 at 3:58 PM, Chris Hegarty > wrote: >> At one point I thought the same, but after, yet another, re-reading of the >> RFC >> I disagree. The semantics are somewhat stronger in WebSocket, albeit that >> the wording is a little squirrely : >> >> 5.5.1 Close [1] >> >> It SHOULD do so as soon as practical. An >> endpoint MAY delay sending a Close frame until its current message is >> sent (for instance, if the majority of a fragmented message is >> already sent, an endpoint MAY send the remaining fragments before >> sending a Close frame). > > And the disagreement is that TCP can send an unlimited amount of data > in half closed state, while WebSocket *seems* to hint that it *may* > send a *non specified* amount of fragments ? Correct. The wording is somewhat stronger than a *hint*, but I agree that it is not mandated. What Pavel is trying to do with onClose is to adhere to the spirit of the RFC, rather than supporting open-ended half-close semantics. -Chris.
RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing
Hi, can I please get a review the following change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8160174 I made further fixes and cleanups for listing Unix type network interfaces, especially on AIX and Linux. I ran builds and verified also on Solaris and Mac. Thanks Christoph
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Hi,
On Thu, Jun 23, 2016 at 4:09 PM, Pavel Rappo wrote:
> Is this some kind of a clever sarcasm, designed to point out the ambiguity in
> question?
Nope.
> Because I actually meant the *application*. Consider the following
> flow of events (let's assume a simplified scenario where all CFs from sendText
> are returned already completed):
>
> |->sendText("...", false);
> |->sendText("...", false);
> |<-onClose()
> |->sendText("...", false); (A)
> |->sendText("...", true); (B)
>
> onClose() has been received, but the application can still send messages until
> the last chunk has been finally sent. Do you agree with this?
Sure.
However, here's another examples that shows the ambiguity:
|-> sendBinary(huge, true);
|<- onClose()
The implementation will fragment "huge", or the write will be
incomplete, so that "huge" is not fully sent yet.
When the onClose() is received, who is it that is sending the frames ?
Certainly not the application, since the sendBinary() call returned.
It's the implementation that is sending the frames when onClose() arrives.
>> I think this is wrong.
>> Leaving room to "implementation specific" details is allowing for
>> writing applications that are not portable.
>
> We're talking about an extremely rare corner case, where we guarantee that a
> new
> message WILL NOT be sent to the server.
Why not ?
> The difference is how the WebSocket will
> react on attempting to do so.
>
> Okay, I'm fine with REQUIRING is a new message is a attempted to be send, WS
> will send a Close message instead and complete the CF returned from send
> operation exceptionally.
Why you want to deny the possibility of sending data in half closed state ?
Implementation wise is simple, semantic is simple, is there a specific reason ?
> I'm not a TCP expert. Does TCP allow an endpoint to skip the data it receives
> after this endpoint has half-closed the connection? Because WebSocket does:
>
>...However, there is no guarantee that the
>endpoint that has already sent a Close frame will continue to process
>data...
See, the sentence after that is:
"After both sending and receiving a Close message, an endpoint
considers the WebSocket connection closed and MUST close the
underlying TCP connection."
Which tells that an endPoint closes the TCP connection when it is
fully closed (2 halves).
So, if you *have* to continue reading from the network to read the
reply close frame, what do you do with the data that you read in
between ?
You throw it away ?
I guess that is "legal" too, but I would stay on the side of
reasonable behavior, not trying to literally adhere to a non-normative
vague wording.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Hi, On Thu, Jun 23, 2016 at 4:40 PM, Chris Hegarty wrote: > What Pavel is trying to do with onClose is to adhere to the > spirit of the RFC, rather than supporting open-ended half-close semantics. Not sure there is a spirit to RFCs, just interpretations. I doubt the "spirit" of the RFC was to deny completely the send of messages in half closed state. If it was so, it would have probably been stated so clearly. Web*Socket* was born as a thin layer on top of sockets, so TCP, that is why I keep referring to that. I'm fine that mine interpretation is different from Pavel's, we're just discussing different interpretations here and try to come out with a good/common one. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
> On 23 Jun 2016, at 16:01, Simone Bordet wrote: > > Hi, > > However, here's another examples that shows the ambiguity: > > |-> sendBinary(huge, true); > |<- onClose() > > The implementation will fragment "huge", or the write will be > incomplete, so that "huge" is not fully sent yet. > When the onClose() is received, who is it that is sending the frames ? The implementation. Sure. > Certainly not the application, since the sendBinary() call returned. > It's the implementation that is sending the frames when onClose() arrives. > >>> I think this is wrong. >>> Leaving room to "implementation specific" details is allowing for >>> writing applications that are not portable. >> >> We're talking about an extremely rare corner case, where we guarantee that a >> new >> message WILL NOT be sent to the server. > > Why not ? > >> The difference is how the WebSocket will >> react on attempting to do so. >> >> Okay, I'm fine with REQUIRING is a new message is a attempted to be send, WS >> will send a Close message instead and complete the CF returned from send >> operation exceptionally. > > Why you want to deny the possibility of sending data in half closed state ? > Implementation wise is simple, semantic is simple, is there a specific reason > ? > >> I'm not a TCP expert. Does TCP allow an endpoint to skip the data it receives >> after this endpoint has half-closed the connection? Because WebSocket does: >> >> ...However, there is no guarantee that the >> endpoint that has already sent a Close frame will continue to process >> data... > > See, the sentence after that is: > > "After both sending and receiving a Close message, an endpoint > considers the WebSocket connection closed and MUST close the > underlying TCP connection." > > Which tells that an endPoint closes the TCP connection when it is > fully closed (2 halves). > So, if you *have* to continue reading from the network to read the > reply close frame, what do you do with the data that you read in > between ? > You throw it away ? > I guess that is "legal" too, but I would stay on the side of > reasonable behavior, not trying to literally adhere to a non-normative > vague wording. Is that how it works in Jetty? Joakim has mentioned once his view on the correct behaviour here [1], which actually made me re-read the RFC and agree with him: ...Close should occur after the actively being sent message (aka once a fin==true is encountered in the frame queue)... Have a look at this testcase: http://autobahn.ws/testsuite/reports_20131013/clients/autobahnpypy_case_7_1_6.html Interestingly enough, the Pong is not sent back. Yes, there's a variability in the test expected, but only in the amount of echoed text data, but they do not expect Pong. Thanks, -Pavel [1] http://mail.openjdk.java.net/pipermail/net-dev/2016-June/009936.html
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
On 23 Jun 2016, at 16:09, Simone Bordet wrote: > > Hi, > > On Thu, Jun 23, 2016 at 4:40 PM, Chris Hegarty > wrote: >> What Pavel is trying to do with onClose is to adhere to the >> spirit of the RFC, rather than supporting open-ended half-close semantics. > > Not sure there is a spirit to RFCs, just interpretations. > I doubt the "spirit" of the RFC was to deny completely the send of > messages in half closed state. > If it was so, it would have probably been stated so clearly. > Web*Socket* was born as a thin layer on top of sockets, so TCP, that > is why I keep referring to that. > > I'm fine that mine interpretation is different from Pavel's, we're > just discussing different interpretations here and try to come out > with a good/common one. After some further research it seems like this is a debatable point. Keeping the Design Philosophy ( not spirit ) in mind, and erring on the side of caution, it may be best to NOT impose a, possibly artificial, restriction on the Java API. So, in summary, I agree with your proposal around the handling of OnClose, we should support half-close semantics. -Chris.
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Simone, please disregard the link to the test I gave you. My apologies. This test has nothing to do with starting a new message after a Close message has been received. It just verifies that the endpoint stops reading after receiving onClose. So not sending back a Pong is perfectly natural in this case. But I still think we probably more safe assuming the intersection of our understandings, rather than a union :-) > On 23 Jun 2016, at 16:20, Pavel Rappo wrote: > > >> On 23 Jun 2016, at 16:01, Simone Bordet wrote: >> >> Hi, >> >> However, here's another examples that shows the ambiguity: >> >> |-> sendBinary(huge, true); >> |<- onClose() >> >> The implementation will fragment "huge", or the write will be >> incomplete, so that "huge" is not fully sent yet. >> When the onClose() is received, who is it that is sending the frames ? > > The implementation. Sure. > >> Certainly not the application, since the sendBinary() call returned. >> It's the implementation that is sending the frames when onClose() arrives. >> I think this is wrong. Leaving room to "implementation specific" details is allowing for writing applications that are not portable. >>> >>> We're talking about an extremely rare corner case, where we guarantee that >>> a new >>> message WILL NOT be sent to the server. >> >> Why not ? >> >>> The difference is how the WebSocket will >>> react on attempting to do so. >>> >>> Okay, I'm fine with REQUIRING is a new message is a attempted to be send, WS >>> will send a Close message instead and complete the CF returned from send >>> operation exceptionally. >> >> Why you want to deny the possibility of sending data in half closed state ? >> Implementation wise is simple, semantic is simple, is there a specific >> reason ? >> >>> I'm not a TCP expert. Does TCP allow an endpoint to skip the data it >>> receives >>> after this endpoint has half-closed the connection? Because WebSocket does: >>> >>> ...However, there is no guarantee that the >>> endpoint that has already sent a Close frame will continue to process >>> data... >> >> See, the sentence after that is: >> >> "After both sending and receiving a Close message, an endpoint >> considers the WebSocket connection closed and MUST close the >> underlying TCP connection." >> >> Which tells that an endPoint closes the TCP connection when it is >> fully closed (2 halves). >> So, if you *have* to continue reading from the network to read the >> reply close frame, what do you do with the data that you read in >> between ? >> You throw it away ? >> I guess that is "legal" too, but I would stay on the side of >> reasonable behavior, not trying to literally adhere to a non-normative >> vague wording. > > Is that how it works in Jetty? Joakim has mentioned once his view on the > correct > behaviour here [1], which actually made me re-read the RFC and agree with him: > >...Close should occur after the actively being sent message (aka once a >fin==true is encountered in the frame queue)... > > Have a look at this testcase: > > > http://autobahn.ws/testsuite/reports_20131013/clients/autobahnpypy_case_7_1_6.html > > Interestingly enough, the Pong is not sent back. Yes, there's a variability > in the test > expected, but only in the amount of echoed text data, but they do not expect > Pong. > > Thanks, > -Pavel > > > [1] http://mail.openjdk.java.net/pipermail/net-dev/2016-June/009936.html >
Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior
Hi, On Thu, Jun 23, 2016 at 7:00 PM, Pavel Rappo wrote: > But I still think we probably more safe assuming the intersection of our > understandings, rather than a union :-) Chris and I agreed, so now you're minority :) -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"
Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1f3481f377e6 -Chris. > On 23 Jun 2016, at 10:41, Chris Hegarty wrote: > > Sergey and I discuss this off-line and the potential performance improvement > here is very significant; raises performance from 25 request/sec to 6000 > requests/sec in one particular test. > > I think we should proceed with this change, unless there are strong > objections. > > We can revisit this later, if necessary. And/Or make implementation changes > if issues arise from this. > > -Chris. > >> On 21 Jun 2016, at 06:56, Chris Hegarty wrote: >> >> On 20 Jun 2016, at 21:36, Sergey Kuksenko wrote: >>> >>> 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 >> >> Hmmm….. I’m not sure that disabling Nagle is the right thing to do, >> at least not without doing further investigation about the size / chunks >> of data that can be sent. Though I do note that the old >> HtpURLConnection implementation does set setTcpNoDelay(true), >> while buffering the data to be written. >> >> -Chris. >
