GeeCON Prague 2014*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Servlet without timeout Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Servlet without timeout" Watch "Servlet without timeout" New topic
Author

Servlet without timeout

Rajesh Pathak
Ranch Hand

Joined: Aug 15, 2002
Posts: 56
In the deployment descriptor, I have set
<session-timeout>0<session-timeout> for a servlet, so that session never expires.
Now, in a scenario where many users are connected and none of the users 'logout', will it create too much burden to the container?


Rajesh(Bangalore,India)<br />SCJP2, SCWCD, SCEA, IBM-XML, UML-OOAD, IBM-Enterprise Connectivity with J2EE.
Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
I'm pretty sure if the user closes their browser their session will be killed. Someone correct me if this is wrong, I don't know this to be a fact.
Yu Chen
Greenhorn

Joined: Dec 03, 2001
Posts: 28
There are 2 ways to kill a session:
1) HttpSession.invalidate;
2) or session timeout has expired.
Another mock exam question states that even the container is shutdown and brought up again, the session still persists.
-yu chen


SCJP2<br />SCWCD
Rajesh Pathak
Ranch Hand

Joined: Aug 15, 2002
Posts: 56
Yeah, yu Chen, the two ways you mentioned are perfect. But, my question is, if there are thousands/millions of active sessions(and unused) and we are not killing the session will it create unwanted burden on the container?
Thanks.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Sessions surely do impose a burden on the container.
  • If your servlet uses sessions, or if your JSP does not specify session="false", every visitor gets a session eating up a bit of memory. Memory requirements become directly proportional to load.
  • Distributed containers share sessions between JVMs, meaning that session data is serialized over the network (often by storing it in a database, e.g. WebSphere). The overhead involved is proportional to both the number of sessions and the size of your session data; store more than 2-4KB of session data and performance under load sinks through the floor.
  • A quick example: if your JVM has 1GB of memory allocated to it, half of this is available for session data with a 4KB footprint per session, sessions take half an hour to time out, and an average user spends 10 minutes on your site, you are memory-limited to 524,288/4 * 10/(10+30) = 32,768 simultaneous users per server. This is fine; CPU and I/O constraints are likely to limit you to 1,000 - 10,000 users per server anyway.
    On the other hand, if you have only 128MB available for session data, you happily store 100KB worth of garbage in the session (don't laugh, I've seen this and worse), and users spend an average of 3 minutes on your site, you are memory-limited to 131,072/100 * 3/(3+30) = 119 users. You will run out of memory long before you run out of CPU or I/O bandwidth.
    I should really add that these example assume that the container does not passivate sessions. If it does, in the last example, the container can passivate the session shortly after the user has left the site (3 mins) without impacting performance too much, improving scalability tenfold to about 1000 users. Memory would still represent a significant bottleneck though.
    When building massively scalable sites or applications, avoid sessions as much as you can, time them out as quickly as you can, and aggressively invalidate them wherever you can.
    - Peter
    [ September 05, 2002: Message edited by: Peter den Haan ]
    Rajesh Pathak
    Ranch Hand

    Joined: Aug 15, 2002
    Posts: 56
    Thanks Peter, it was very informative.
    Peter den Haan
    author
    Ranch Hand

    Joined: Apr 20, 2000
    Posts: 3252
    Upon rereading, I haven't directly addressed the question: yes, never timing out sessions is just about the worst possible thing you can do; unless you invalidate sessions in another way, session data will only grow. Good containers will passivate them, but a passivated session often still has a small memory footprint. Ultimately you will run out of memory or disk space.
    Even if you have some other mechanism of invalidating sessions, it is very hard to guarantee that a session will be invalidated. Browsers may crash, networks may go down and your magic code may never be called. So I would always want to set a (very long) timeout to give me that guarantee.
    - Peter
    [ September 05, 2002: Message edited by: Peter den Haan ]
     
    GeeCON Prague 2014
     
    subject: Servlet without timeout