Thanks for the questions. I'm not sure if I'll answer them, but here's how I was seeing it:-
It looks to me like the information we have about the session comes from two places: one from the state of underlying TCP connection, and second from the protocol itself. That information is incomplete, but I hope we can provide something coherent to the user (not sure the API does it exactly yet)
It looks like the session has 3 states that we could usefully model:-
1. 'ok' the underlying TCP connection has been established, it may or may not be in the middle of transmitting/receiving data
2 a) 'broken': the underlying TCP connection has failed, network problem, or it timed out.
2 b) 'formally closed': the peer in the interaction has formally closed the session by sending a close frame.
Most of the time, my own guess is that developer will only care about either 1) or 2) but not which flavor of 2 - a) or b).
The intention of isActive was to model 1 : isActive() true, and 2a)or2b) : isActive() false.
And getCloseStatus() was returning the close frame sent by the peer if the session is in state 2b). So getCloseStatus() being null could either be 2a) or 1.
My thought was that states 1 vs 2a) are essentially derived from the health of the underlying TCP connection (is that not cheap to determine?).
And a determination of being in state 1) is no guarantee the connection will not fail the next moment, but I think its still useful information, as is the inactive time determined by when the container marks the last activity on the TCP connection. I think this kind of approach has been ok for HttpSession's over the years.
Whether the connection was closed because someone cut the physical wire, or whether the client send a close frame is I suspect of little interest to most developers...so maybe there's a cleaner way to model these states in the API while keeping the close frame info for those who want it ?
The protocol specific connection check is of course to do a Ping-Pong, which is expensive. Maybe we should have some sort of checkActive() method that does that in addition to the Ping/Pong APIs we have ?
On 8/6/12 12:24 PM, Bill Wigger wrote:
[jsr356-experts] Re: Session.getCloseStatus isActive and getInactiveTime