Hi Bill,
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 ?
- Danny
On 8/6/12 12:24 PM, Bill Wigger wrote:
>
> I have a question on the uses of the Session.getCloseStatus,
> .isActive, and .getInactiveTime
>
> getCloseStatus and isActive seem redundant in that if getCloseStatus
> returns null then it is Active. But beyond that I think that the
> information it supplies is not very useful and is supposing too much
> about the underlying communication protocol.
>
> From a useful standpoint, that status can change the moment after it
> is given, so just because the session returned as active, doesn't mean
> the calling code can assume it is active, since it could have been
> closed the moment after returning as active. And since the user can
> implement a close listener, then they already have a good way of
> knowing when it has been closed.
>
> Beyond usefulness though is the idea that the underlying protocol has
> a decent way of determining if a connection is closed or not. For
> some protocols on some operating systems one doesn't know, or at least
> cannot determine in an efficient manner, if the connection has been
> closed until a read or write fails, so if you don't have a read or
> write outstanding then there is no efficient way to determine if the
> connection has been closed. That's my biggest concern here, requiring
> the underlying subsystem to keep track of connection state and thereby
> producing a performance drag. And since the information can change
> momentarily, it doesn't seem like the upside of giving the
> (changeable) state back to the user is worth the downside of having to
> keep track of it.
>
> For getInactiveTime, I have basically the same concerns. That time
> can change momentarily, and if the intent here is to tell the user
> when, for example, read data has last come into the box, without the
> user having a read outstanding (in the form of a listener), then there
> isn't an efficient way to keep track of that information, and keeping
> track of it could be a drag on performance and scaling.
>
> Maybe I'm just misunderstanding what the information is that these
> APIs are suppose to relay, if so, please let me know.
>
> thank you,
> Bill
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation