From: Bill Wigger <wigger_at_us.ibm.com>
Date: Fri, 30 Nov 2012 13:18:42 -0500

Danny,

thanks for your replay. I'm still not a big fan of the call, but I'm ok
with leaving it in there, as long as the
scope of it is related to the receiving of the websocket close frame, and
not the underlying socket close.

I had a another post about the getInactiveTime() method, please let me know
your thoughts on that also.


regards,
Bill



From: Danny Coward <danny.coward_at_oracle.com>
To: jsr356-experts_at_websocket-spec.java.net,
Cc: Bill Wigger/Raleigh/IBM_at_IBMUS
Date: 11/28/2012 05:23 PM
Subject: [jsr356-users] [jsr356-experts] Re: isActive() method removal
            from API



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.

- 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

--
                   Danny Coward
                   Java EE
                   Oracle Corporation