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.
Danny 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 <
Cc: Bill Wigger/Raleigh/IBM@IBMUS
Date: 12/04/2012 08:23 PM
Subject: [jsr356-experts] Re: [jsr356-users] getInactiveTime() method removal from API
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 ?
On 11/26/12 12:38 PM, Bill Wigger wrote:
On the Session object is this method:
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?
|Danny Coward |