If a user doesn't use cookies and you don't use response.encodeUrl() then each request for a jsp will create a new session that will be killed after the session timeout.
If you don't need sessions you can use <%@ page session="false" %> in each jsp. Otherwise you should encode all links in your site. encodeUrl() is a method that adds a sessionid to a url if cookies are disabled. This way tomcat can recognize the session to which the request belongs. (As HTTP is a stateless protocoll there is no other way) setMaxInactiveInterval() is a method to set the minimal time between the last request in a session and the termination of the session. It can be used to set the timeout programatically. (In most cases it's enough to define the timout in the setup) > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 02, 2002 11:32 PM > To: Julius Davies > Cc: Tomcat Users List > Subject: RE: Memory/Performance > > > I do not use cookies and I do not call > "session.setMaxInactiveInterval()" or > "session.invalidate()" or response.encodeURL(). In fact I am > completely ignorant about these calls. I assume my sessions > are closed automatically by tomcat when there is no usage from > that client for 15 minutes. So can > I assume session.invalidate() kills a session. How and in > what situation would I use this method? > > What does setMaxInactiveInterval do and how is that applied? > > > And same questions on response.encodeURL()? > > > So you are saying that possible it is not only creating a new session > per new user but per page each user accesses? > If so please teach me how to fix my problems with my coding. > > -ryan > > > On Mon, 2 Dec 2002, Julius Davies wrote: > > > > > Developer, > > > > Hello. I use Tomcat 4.1.12 standalone. I was just > thinking about what you were saying, especially "[...] I > would think the memory stamp would correspondingly shrink > when all these sessions are closed and it doesn't". > > > > I noticed this section in the default "web.xml": > > > > <!-- ==================== Default Session Configuration > ================= --> > > <!-- You can set the default session timeout (in minutes) > for all newly --> > > <!-- created sessions by modifying the value below. > --> > > > > <session-config> > > <session-timeout>30</session-timeout> > > </session-config> > > > > So, by default on my machine sessions will stay around for > 30 minutes, unless either "session.setMaxInactiveInterval()" > or "session.invalidate()" was called. I haven't changed this > file since I installed Tomcat, and so I'm assuming you have > the same file. > > > > Are you calling either of those methods - invalidate or > setMaxInactiveInterval? Or when you say "these sessions are > closed", do you mean they time out after 30 minutes? > > > > Secondly, what are you doing to generate all this > (server-crashing!) load? Obviously you're not going to call > "session.invalidate()" on the same page that you created the > session. That would be pointless... so here comes an > interesting possibility: suppose a significant portion of > your load didn't support cookies? Or, if you were using URL > rewriting for the sessions, suppose you forgot to use > "response.encodeURL()"? In both cases the result is the same: > > > > Sessions are being created for a client, but the client > won't remember his special "session id". This means a new > session is created for this client with every request he makes! > > > > So, I have three questions I need to know: > > > > 1.) What kind of load is Tomcat experiencing on your > machine, and where is this load coming from? > > > > 2.) Does your load support cookies? Is the "session id" > being remembered by the client? > > > > 3.) How are you closing your sessions? > > > > Suppose each of your sessions weighed in at 512 bytes. If > your load, at, let's pretend 10/hits second, didn't support > cookies, you're going to need ~15mb to hold on to 30 minutes > of sessions before they start expiring. This is because each > hit is going to create a new session. > > > > Tomcat User please correct any mistakes I may have made here! > > > > > > Julius Davies, Programmer, CUCBC > > Email: [EMAIL PROTECTED], Ph: 604.730.6385 > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, December 02, 2002 1:24 PM > > > To: Tomcat Users List > > > Subject: Re: Memory/Performance > > > > > > > > > Thanks for your comments. Well all my jspcode is definitely > > > session happy > > > and I am creating several > > > objects per session. The objects I am creating consist of mostly > > > string, int and floats, probably up to like 20 of each. > > > Although i create > > > a large application pool of jdbc > > > connections I am fairly positive that this is not the problem > > > because I > > > use this pooling model in several applications that don't > > > seem to have a > > > problem. I realize that every time a session is created all > > > these objects > > > must be allocated, and that should cause the memory blob to > > > keep growing > > > as the session count increase but I would think the > memory stamp would > > > correspondingly shrink when all these sessions are closed and it > > > doesn't. I am basing this on tomcats crashing or slow behavior > > > in conjunction with monitoring the processes and memory > > > usage. What other > > > information can I share that would help? Like I said I don't > > > know if this > > > is tomcat or me or a bit a both so I am jsut throwing out > > > what seems to be > > > going on and looking for insight? > > > > > > > > > > > > > > > On Mon, 2 Dec 2002, Michael Nicholson wrote: > > > > > > > I suppose it depends on what you're doing, which, > > > unfortunately, I don't > > > > know. > > > > > > > > If you're overly filling your session w/ objects, or if you > > > have a session > > > > scoped bean that is spiraling out of control or something, > > > that might lead > > > > to the problem, or if you create/leave open jdbc > > > connections or stuff like > > > > that. I'm running tomcat 4.03 on a much less beefy system, > > > and I don't ever > > > > notice any memory issues, now that I make sure I close > and null my > > > > connections and such. > > > > > > > > More info on what's happening might help, though.. > > > > > > > > > > > > ----- Original Message ----- > > > > From: <[EMAIL PROTECTED]> > > > > To: "Tomcat Users List" <[EMAIL PROTECTED]> > > > > Sent: Monday, December 02, 2002 3:51 PM > > > > Subject: Memory/Performance > > > > > > > > > > > > > I find that tomcat's memory stamp grows continually until > > > eventually there > > > > > are out of memory errors or it just bogs down. I am > > > running on jdk1.4_1, > > > > > tomcat 4.1.12, apache 1.27, mod_jk on the linux 2.2 > > > kernel. The box I am > > > > > operating on has 1gig of memory and has dual gigahertz > > > processors. I > > > > > believe that tomcat has some serious memory leaks and/or > > > I am not writing > > > > > my jsppages properly. So i would like to ask two questions: > > > > > > > > > > > > > > > 1)Assuming tomcat has memory issues what can I do to > control them? > > > > > > > > > > > > > > > > > > > > > > > > > 2)What techniques would you suggest to write jsppages > > > that help keep > > > > > memory consumption down? Are there ways to write > > > jsppages that makes them > > > > > more "garbage collection friendly"? > > > > > > > > > > please comment.... > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
