Keep in mind, too, that guarantees like this will always come with a certain
amount of overhead. It's a given facet of distributed computing that we
cannot know, without some form of communication overhead, when the user dies
or quits. RMI carries it with DGC, for example. HTTP scales so well
precisely because it *doesn't* provide anything of that form.
Also, if you're site is looking at 1000 concurrent users, I'd be thinking
along the lines of upping your webserver system to a clustered collection of
servers--a site with that much traffic is going to bog down on other areas
beyond just the heartbeat arena (database connections, for example).
<PATTERNS-SPEAK>
Everything comes with forces that affect the outcome. Understand those
forces, and you can choose the best solution for your problem.
</PATTERNS-SPEAK>
Ted Neward
Java Instructor, DevelopMentor ( http://www.develop.com )
http://www.javageeks.com/~tneward
-----Original Message-----
From: Ron Reynolds <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sunday, December 05, 1999 6:21 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
