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.
On 12/6/12 5:15 AM, Bill Wigger wrote:
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
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