On 11/28/12 2:22 PM, Danny Coward wrote:
> Hi Bill,
>
> Yes, you brought this up some time ago and we never resolved it.
>
> As you point out doing an explicit test on the TCP connection is
> expensive/unreliable. So I agree the notion of 'active' is not realistic.
>
> What the websocket protocol does give us however is are the open and
> close frames. I think its a useful concept for developers to be able
> easily to list out the connections which the protocol has notified
> have been opened, but have not notified that they are closed. In other
> words, I think its going to be a very common (and repetitive) pattern
> in server code to maintain a list of such 'open' connections, even if
> they still need to code around cases where one or two rogue
> connections have simply vanished without telling anyone.
>
> I'd propose we rephrase/name these API calls to be based on what the
> websocket protocol gives us (open/close frames), which I think
> addresses the expense/reliablity issue you bring up, which relieving
> the developer of what I think is a common programming task.
I agree the spec should be written around close.
Because websockets is duplex, we do know if the connection closes,
because the read side will return as soon as the connection drops.
There's no need to test the write side.
-- Scott
>
> - Danny
>
>
>
>
> On 11/26/12 1:00 PM, Bill Wigger wrote:
>>
>> Sorry, I have another method I would like to get rid of, or be
>> enlightened about!
>>
>> On the Session object is this method:
>>
>> boolean isActive()
>>
>> Return true if and only if the underlying socket is open.
>> Returns:
>> whether the session is active.
>>
>> What concerns me about this call is the idea that one can easily tell
>> if the socket is open. Using the standard socket API available from
>> the JDK one cannot (at least I don't know how) in a straight forward
>> manner. This is because if the other side closed the connection,
>> then there is no notification given by the JDK to any type of "socket
>> close callback" or "listener". How one finds out that a socket has
>> been closed by the other side is to do a Read or Write on the socket
>> and get an error or "EOF" back.
>>
>> But if a Read or Write fails, then the WebSocket user has already
>> been notified. In the case of the read/onMessage listener I'm
>> assuming it is via the EndPoint onError or OnClose method. In the
>> case of a write/send an IOException would be thrown.
>>
>> So if the user is listening for messages, or sending messages, then
>> they will know right away if the socket is no longer open. If the
>> user is not listening for messages nor sending messages, I don't know
>> how the server will be able to "poll" the connection to see if it is
>> active.
>>
>> regards,
>> Bill
>>
>
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>