Simone,
Based on the answers you've provided, careful thinking and re-reading
appropriate parts of the RFC, I think we might find the following solution a
good compromise. (Please note that here I'm only talking about Close message
representation. Other topics discussed, like returning CS/CF from
Hi,
On Fri, Jun 3, 2016 at 3:36 PM, Pavel Rappo wrote:
> The implication is that you won't be able to do this (for example):
>
> void onClose(WebSocket webSocket, int statusCode, String reason) {
> webSocket.sendClose(statusCode, reason);
> }
>
> Just because the received statusCo
Could I get the following small change reviewed please?
http://cr.openjdk.java.net/~michaelm/8158651/webrev.1/
The exception has been seen in some tests failing intermittently.
So, I have not added a new test
The failure occurs in Http2Connection but a similar case
was found in Stream.java
Tha
> On 3 Jun 2016, at 14:58, Simone Bordet wrote:
>
> The implementation should reply to a Close frame with a Close frame
> with the same code.
> Applications do not need to call sendClose() from within onClose().
It's just this thing can be done. We can't prohibit sending a Close message from
wi
Hi Michael,
Looks ok as long as the response_cfs list can't be shrunk by a different
thread. (cfs_len can be stale).
And 577: probably a printf to system.err isn't the ultimate in
robustness or debugging.
Roger
On 6/3/2016 10:40 AM, Michael McMahon wrote:
Could I get the following sma
Hi Roger,
All access to the list is synchronized.
Yes, I should also remove that printf. It's not required.
Pavel also suggested changing the LinkedList to an ArrayList
when I told him the size is nearly always small (1 or 2 elements).
So, I will also change that.
Thanks
Michael.
On 03/06/16
ok, thanks; +1
(Determining method level thread safety without per method documentation
is a bit of a chore).
On 6/3/2016 11:08 AM, Michael McMahon wrote:
Hi Roger,
All access to the list is synchronized.
Yes, I should also remove that printf. It's not required.
Pavel also suggested chan
