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