Then again, it's all adding extra processing for something that, in most
cases, shouldn't matter. I have not heard a compelling reason why anyone
would have to know the exact moment when a user left their site, if they do,
HTTP is the wrong protocol. Coming up with all these fancy hacks and
work-arounds basically removes thought from the problem at hand, and usually
doesn't add any value to the site. Let the Session time-out and use an
HttpSessionBindingListener if you need to know when it does. You'll, and
your boss, will be happier since you'll get more of what the customer is
paying for done. Just one man's opinion.
(*Chris*)
----- Original Message -----
From: "Ron Reynolds" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 05, 1999 5:26 AM
Subject: Re: [Session tracking]
> well, obviously with a heavy traffic site this solution is much less than
> ideal. i was thinking more along the lines of a very low traffic site
> (small intranets, for instance) where you REALLY WANT TO KNOW when that
> client's machine and/or browser goes down. even without the massive
network
> load the processing load on the server is going to be insane trying to
track
> and determine time outs for thousands or tens of thousands of
connections...
> also there's no reason the heartbeat has to be that fast or even has to be
a
> heartbeat at all. a simpler approach is that when a session is
invalidated
> on the server due to timeout you could "ping" the applet on the client to
> see if the user is there, but sleeping. if no response, throw the session
> away and forget about it. if the user is still staring at the page (i.e.,
> the applet is still around) then perhaps you want to hold onto that
session
> a little longer. this minimizes the traffic to (N*1000)/T (where T is the
> time-out interval, probably something >= 30 seconds). this frees the
server
> up from having to count how long it's been since user X (of N*1000) sent
in
> a heartbeat and adds only 1 transaction per user per time-out interval
> (worst case - that assumes all of your users suddenly fell asleep).
> better? worse? am i totally off track? (wouldn't be the first time,
won't
> be the last). :)
> ................ron.
>
> -----Original Message-----
> From: Preston L. Bannister <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Saturday, December 04, 1999 2:52 PM
> Subject: Re: [Session tracking]
>
>
> >Also note that heartbeats scale very poorly. I expect large numbers of
> low-activity users. Say the number of "connected" users is:
> >
> > N*1000
> >
> >Then the number of heartbeats with one every 5 seconds is:
> >
> > N*1000/5 => N*200 per second
> >
> >So I can expect N*200 requests per second when absolutely nothing is
> happening.
> >
> >This is not a particularly good design...
> >
> >> -----Original Message-----
> >> From: A mailing list for discussion about Sun Microsystem's Java
Servlet
> >> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
Chris
> >> Pratt
> >> Sent: Saturday, December 04, 1999 1:34 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: [Session tracking]
> >>
> >>
> >> So what you're saying is that if you use a heartbeat of about 5 seconds
> (so
> >> you don't overload your network with heartbeats) and then allow the
user
> to
> >> miss, oh let's say 6 heartbeats just for the sake of argument to make
> sure
> >> it's not the insanely heavy network traffic that's in the way, your
user
> >> will be marked as go 30 seconds after his last confirmed heartbeat.
> Seems
> >> like I have the same time lag and I didn't have to do any extra
> programming
> >> to achieve it. =8^)
> >> (*Chris*)
> >>
> >> ----- Original Message -----
> >> From: "Ron Reynolds" <[EMAIL PROTECTED]>
> >> To: <[EMAIL PROTECTED]>
> >> Sent: Saturday, December 04, 1999 6:32 AM
> >> Subject: Re: [Session tracking]
> >>
> >>
> >> > a heart-beat would do it. if, after x seconds, you don't receive a
> >> > heartbeat from your applet you can assume either (a) insanely heavy
> >> network
> >> > traffic, (b) client machine is unbelievably bogged down to a point
> where
> >> the
> >> > applet can't get a time slice, or (c) the client machine is dead
and/or
> >> > disconnected from the network. combine that with simple ping and you
> can
> >> > even determine the difference between the browser being off and the
> >> computer
> >> > being off (again, assuming a stable, non-flooded network). (the
other
> >> way,
> >> > even without power failures, is to terminate the browser process
> >> directly).
> >> > ................ron.
> >
>
>___________________________________________________________________________
> >To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> >of the message "signoff SERVLET-INTEREST".
> >
> >Archives: http://archives.java.sun.com/archives/servlet-interest.html
> >Resources: http://java.sun.com/products/servlet/external-resources.html
> >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
