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
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
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 cer
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
impleme
> 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 i
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 w
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:
Simon
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 a
> 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 wordin
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 verif
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
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 de
> 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
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 RFC
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
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
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
17 matches
Mail list logo
