RFR [9] 8180155: WebSocket secure connection get stuck after onOpen

[Daniel Fuchs]

OK Pavel,

Then this looks good.

-- daniel

On 01/06/2017 14:48, Pavel Rappo wrote:
> 
>> On 1 Jun 2017, at 13:45, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Pavel,
>>
>> I agree it would be good to have a test :-(
>> These kind of complex state logic have a tendency to
>> bite you if you only test them by code reading.
> 
> True. The thing is I would refrain from writing a black-box test in this case.
> The reason is that it would be very non-obvious. I think we can get away with
> descending to a appropriate level of abstraction and test Receiver directly as
> if it was the target system. I will have to provide a suitable implementation of
> RawChannel which would allow us to mimic different corner cases though.
> 
>>> I tried to rewrite the state machine the way that both fixes this bug and makes
>>> the code easier to follow (I'm biased here obviously).
>>
>> Can we throw an InternalError or assert if
>> 124                         reader.readFrame(data, frameConsumer);
>> does not advance the buffer position?
> 
> Makes sense. Done in place.
> 
>> 131                 break;
>> hmmm... what if demand.get() is no longer 0 when we reach this line?
> 
> That would be fine, Daniel.
> 
>> what if the cooperative handler already thinks that the current thread
>> will read the data? Is that possible?
> 
> CooperativeHandler does not care about what it executes. It simply makes sure
> that for each call to `handle`, there will be a subsequent execution. If we go
> one level up, then we will see there's a enclosing (hidden) `while` that
> actually calls `pushContinuously`. So no harm here.
> 
> The `while` loop in `pushContinuously` exists _mainly_ to make sure we
> eventually exhaust either data or demand. Whichever comes first.
> 
> Does it make any sense?
>