• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Servlet without timeout

 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Rajesh Pathak
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
    Posts: 56
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Peter, it was very informative.
     
    Peter den Haan
    author
    Posts: 3252
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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 ]
     
    This tiny ad is suggesting that maybe she should go play in traffic.
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic