From: Bill Wigger <wigger_at_us.ibm.com>
Date: Thu, 6 Dec 2012 08:15:26 -0500

Danny,

Thanks for the feedback.

For this question...
"If the load per second is so high, wouldn't the implementation mark it
less frequently ?"
I guess my thinking is you have to mark each time a Read is done, since you
don't know if that will be the last read for a while, or am I missing
something obvious here? You can play games with how you obtain the
timestamp to lower the cost of that call, but it isn't free.

I think WebSocket read/write frequency may be more intense than HTTP
Request/Response frequency, so we may want to be more sensitive in how much
processing we put on the WebSocket read/write path. Say you have thousands
of WebSocket connections on a single server and run them full out, maybe
doing small data payload reads and writes, but as fast as possible.

I think the main use of the call on the HTTPSession is to allow the
container controlling http sessions to invalidate unused sessions. I don't
think we have that concept stated in the
WebSocket spec, but is that how you think this will/should get used?

WebSockets does have a setTimeout method on the Session class that will
timeout after a given amount of inactivity, and when WebSockets times out
the connection it will also close the connection, so at that point the
connection has been finished on the first timeout.

Of course, timeout scheduling will requiring resetting the timeout
mechanism on every read/write, so that in itself involves a fair amount of
overhead. That may sound trivial, but if we
are talking about a large number of connections trying to get as high as
throughput as possible, it becomes significant.

That makes me think that we may want to include a way to disable timeouts
for a given Session? Like passing a -1 or 0 for a setTimeout value.

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: 12/04/2012 08:23 PM
Subject: [jsr356-experts] Re: [jsr356-users] getInactiveTime() method
            removal from API



Hi Bill,

Thanks for the reminder on this one. We're really just modeling what's on
HttpSession in this regard, do people find the analogous call on
HttpSession a big performance hit there ? If the load per second is so
high, wouldn't the implementation mark it less frequently ?

- Danny

On 11/26/12 12:38 PM, Bill Wigger wrote:


      On the Session object is this method:

      long getInactiveTime()
          Return the number of seconds since the underlying connection had
      any activity.

      I think this is an unnecessary performance burden to place on the
      server. For example, say there are 10,000 active WebSocket
      connections, then for each session, whenever a read or write takes
      place, the timestamp has to be obtained and stored away. Depending
      on the implementation, that could be 1000's of timestamp calls per
      second. On some OSes reading the timestamp is a performance drag to
      be avoided. Also, if on a given connection 10,000 reads and/or
      writes occur, and the "getInactiveTime()" is never called, then that
      is 10,000 wasted readings of the timestamp.

      Also, the return value is not very accurate, and can not be trusted,
      since the moment after getActiveTime is read, it could be outdated by
      an new read or write taking place.

      If users want this functionality it is easy enough for them to add it
      to their own code, since their code is responsible for reading and
      writing data, but I don't see making all connections take this
      performance hit, for something that may rarely get used, and whose
      return value cannot be trusted to be up to date once obtained.

      can we get rid of this method all together?

      regards,
      Bill

--
                   Danny Coward
                   Java EE
                   Oracle Corporation