Hi Bill,
OK, well I don't want the spec to require things that are expensive to
implement particularly when the developer can track this inactive time
himself if he wishes. I've removed it, lets see if anyone asks for it back.
Also, I took your suggestion that a non-positive timeout indicated the
session would never timeout due to inactivity.
Thanks,
- Danny
On 12/6/12 5:15 AM, Bill Wigger wrote:
>
> 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
>
>
> Inactive hide details for Danny Coward ---12/04/2012 08:23:46 PM---Hi
> Bill, Thanks for the reminder on this one. We're really jDanny Coward
> ---12/04/2012 08:23:46 PM---Hi Bill, Thanks for the reminder on this
> one. We're really just modeling what's
>
> 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
>
>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation