Skip to main content

[jsr356-experts] Re: Session.getCloseStatus isActive and getInactiveTime

  • From: Danny Coward < >
  • To:
  • Cc: Bill Wigger < >
  • Subject: [jsr356-experts] Re: Session.getCloseStatus isActive and getInactiveTime
  • Date: Thu, 09 Aug 2012 16:55:49 -0700

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 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:
" type="cite">

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,

Danny Coward
Java EE
Oracle Corporation

[jsr356-experts] Session.getCloseStatus isActive and getInactiveTime

Bill Wigger 08/06/2012

[jsr356-experts] Re: Session.getCloseStatus isActive and getInactiveTime

Danny Coward 08/09/2012

[jsr356-experts] Re: Session.getCloseStatus isActive and getInactiveTime

Bill Wigger 08/10/2012
Please Confirm