Thanks the reply, you taught me a couple things. My email that is on this
list is on my home
computer and unfortunately the power has been out on my street all day so
I am just reading this now. realize when I say 1 million unique hits I
mean unique page visits not unique users, its close but still not the
same. I still think i am pretty cool though. hahaha.
You are right I am using cookies to keep my sessionid in check. I have
been doing some tests and watching the logs when I login I see the
SessionListener messages with all the session
created and all the attribute added info. I have timed it and when a
session goes inactive for the session timeout time it then issues the
sessiondestroyed and attribute removed commands. It certainly seems to
work properly, and it is not allocating a new session per page. I might
add that session.invalidate just to be safe
though. Looking at your suicide example and some of the responses from
others on the list I am wondering what constitutes too much in terms of
allocating session objects? Is there anyway to trace how big sessions are
growing to?
It is difficult dealing with these problems while I am on my production
box here, but when I initially
rolled out the tomcat powered site it didn't have quite as much going on
and was only like 20 jsp pages now it is a couple hundred pages and lots
more beans per session. Tomcat was certainly a lot stabler when the site was
a lot more cut and dry. I migrated recently from 3.2 to 4.1.12 hoping
that would help with some of these problems but the problems still seem
to be there just with different error messages. I have another tomcat
server up running just some
servlets that never create any session objects. That server seems never
to have any of these problems. So I am certainly fishing for problems in
my jsp code. I also tend to think there are more problems with the JDK
rather than tomcat.
You know I get these warning constantly do you know what the heck that is
all about?
Dec 3, 2002 3:31:47 PM org.apache.jk.common.ChannelSocket
processConnection
WARNING: server has closed the current connection (-1)
And I also get some of these, do you know what this means?:
Dec 3, 2002 1:23:20 PM org.apache.jk.server.JkCoyoteHandler action
SEVERE: Error in action code
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:380)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:558)
at
org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:354)
at org.apache.coyote.Response.action(Response.java:216)
at org.apache.coyote.Response.finish(Response.java:336)
at
org.apache.coyote.tomcat4.CoyoteResponse.finishResponse(CoyoteResponse.java:504)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:224)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:256)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:361)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:563)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:535)
at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:638)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533)
at java.lang.Thread.run(Thread.java:536)
thanks julius and everyone else
Please keep helping
ryan
On Mon, 2 Dec 2002, Julius Davies wrote:
>
>
> ryan,
>
> Wow! You get 1 million unique hits a month (1 unique hit every 2 seconds) handled
>by a single pc running linux. That's awesome! When I was originally writing, I
>didn't realize you were dealing with live, production issues... I hope I can help.
>
> In my office I don't have direct access to that kind of load, and so I have to
>simulate it. My original comments were more coming from that direction: I pictured
>you running some home-grown load test which forgot to take cookies into account, and
>consequently was experiencing a memory spike.
>
> In real production usage almost all the clients support cookies. Very rare for a
>person to have "cookies" disabled in their browser.
>
> >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.
>
> The good news in reply to this: a new session per page access is (very) unlikely. I
>didn't mean to scare you. I didn't realize the performance problems you were
>reporting were real life. My thinking originally had me imagining that a problem
>like you were experiencing would come from over-zealous simulation. The bad news is,
>I guess, that your problem is currently impairing your production website!
>
> >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?
>
> If you ever use "session.setAttribute()" or "session.getAttribute()" in a jsp, then
>you are using cookies. There's a chance you are using URL rewriting instead, but
>that's not the default behaviour. The default behaviour is to use cookies. Tomcat
>will do this whether you use the "session" object or not, but it only starts to weigh
>down your application when you start calling "setAttribute()" on it. For example,
>this would be suicide:
>
> =================================
> suicide.jsp
> =================================
> <%
> // Allocate huge StringBuffer:
> StringBuffer buf = new StringBuffer( 1000000 );
> session.setAttribute( "Big-Waste-O-Space", buf );
> %>
> <html>
> <head>
> <title>Help!</title>
> </head>
> <body>
> <h1>Help!</h1>
> <p>I'm running out of memory!</p>
> </body>
> </html>
> =================================
>
> On the other hand, you'd have a hard time noticing:
>
> =================================
> session.setAttribute( "Small-Waste-O-Space", new Integer( 42 ) );
> =================================
>
> Now, a short tutorial. Since http is stateless, the concept of a "session" takes
>some effort. How does Tomcat remember the user?
>
> Let's use, for example, this jsp, named "hello.jsp":
>
> =================================
> hello.jsp
> =================================
> <% Object o = session; %>
> <html>
> <head>
> <title>Welcome</title>
> </head>
> <body>
> <h1>Hello</h1>
> <p>Welcome to my page.</p>
> </body>
> </html>
> =================================
>
> As you can see, the "session" object is mentioned by name. But nothing interesting
>is done to it. Look at the headers Tomcat responds with, however, when I try to
>telnet into my server:
>
> =================================
> haplo $ telnet localhost 8080
> Trying...
> Connected to localhost.
> Escape character is '^]'.
> GET /hello.jsp HTTP/1.0 <-- I'm typing this by hand.
>
>
> HTTP/1.1 200 OK
> Content-Type: text/html;charset=ISO-8859-1
> Connection: close
> Date: Tue, 03 Dec 2002 05:34:43 GMT
> Server: Apache Tomcat/4.0.4-b2 (HTTP/1.1 Connector)
> Set-Cookie: JSESSIONID=24BF830B73E7C313909FC4255DD3CD44;Path=/
>
>
>
> <html>
> <head>
> <title>Welcome</title>
> </head>
> <body>
> <h1>Hello</h1>
> <p>Welcome to my page.</p>
> </body>
> </html>
>
> Connection closed.
> =================================
>
> That "Set-Cookie" header is the cookie Tomcat expects me to quote back to it on any
>subsequent requests I may make from now on. That's how the notion of a "session" is
>possible: big random strings that no-one else in their right mind would ever think
>to mention in their day-to-day http requests.
>
> Watch what a modern browser then says on a subsequent request (as opposed to my
>hand-typing telnet browser :-] ):
>
> =================================
> GET /index.jsp HTTP/1.1
> Host: localhost:8080
> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2a) Gecko/20020913
> Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
> n;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
> Accept-Language: en-us, en;q=0.50
> Accept-Encoding: gzip, deflate, compress;q=0.9
> Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> Keep-Alive: 300
> Connection: keep-alive
> Cookie: JSESSIONID=24BF830B73E7C313909FC4255DD3CD44
> Cache-Control: max-age=0
>
>
> =================================
>
> The difference is small: the server says "Set-Cookie:" and the browser says
>"Cookie:".
>
> Notice how I'm cheating: I cut & paste the original JSESSIONID from my telnet
>session into this one. That's called "hijacking" a session. My Mozilla browser is
>now masquerading as my original telnet browser. Tomcat thinks they are the same
>person. Okay, that was probably too confusing... consider it a joke for the
>Tomcat-User list.
>
> But, I hope you see how it works: Tomcat provides ("Set-Cookie:") a special
>"secret code" for the browser to identify itself with from then on. By even coming
>up with that "secret code", Tomcat has to allocate some resources so that Tomcat can
>later recognize that same code when it is quoted back ("Cookie:") by the browser. As
>you can imagine, Tomcat probably gives out more secret codes than it ends up getting
>back... people might leave the site after the first page, or their browser might just
>not support that header:
>
> Cookie: JSESSIONID=24BF830B73E7C313909FC4255DD3CD44
>
> That doesn't mean Tomcat can afford to forget any of them.
>
> If Tomcat doesn't recieve the "secret code" (the cookie) for a specified amount of
>time, in your case, 15 minutes, Tomcat forgets about it. The code and the objects
>associated with the session are dropped.
>
> In summary: in real-life use, the abstraction of a "session" provided to jsp
>writers by Tomcat and other web containers is going to work perfectly fine, with no
>resource compromise. Your well-designed application already needed those resources
>stored in the session anyway. Sessions only add a few more references/pointers (at 4
>bytes a shot - cheap!) to those resources.
>
> Over 99% of browsers support cookies. There are no hidden dangers with sessions.
>
> Now, onto the rest of email.
>
> > I assume session.invalidate() kills a session. How and in what situation
> would I use this method?
>
> Use it on a "logoff.jsp". Inside "logoff.jsp" just paste:
>
> ============================
> <% session.invalidate() %>
> ============================
>
> > I assume my sessions are closed automatically
> by tomcat when there is no usage from that client for 15 minutes.
>
> That is correct. Tomcat probably calls "invalidate()" just like you would on a
>"logoff.jsp" page. Code re-use. :-)
>
> > What does setMaxInactiveInterval do and how is that applied?
>
> You could use this to override the 15 minute application-wide timeout you've
>configured on a per/jsp or per/servlet basis. For example, maybe you would like to
>set you "login.jsp's" session timeout to 2 minutes, but after the user successfully
>logs in set it back to 15 minutes. This way people who fail to login, or don't
>bother trying, use up less session resources. However, once you've set the session
>to 2 minutes on one page, it's going to stay 2 minutes unless you state otherwise
>somewhere else.
>
> I imagine that would work. I wouldn't bother messing around like that, though. Too
>finicky. Buy a 2nd server and cluster them. :-)
>
> > And same questions on response.encodeURL()?
>
> This only applies if you're not using cookies. But it's not a bad idea - makes your
>application more portable, since the cookie/no-cookie configuration is administrator
>controlled, not developer controlled. Basically you run every internal link (to
>other jsps or servlets) through "encodeURL()", et voila, sessions without cookies if
>ever needed. I haven't used this, so my explanation here may be a little fluffy.
>
>
> >Tomcat starts out with 128 megs and baloons up pretty quickly to 300 megs. It
> >often exceeds that, there also seems to be a huge thread count.
>
> Perhaps you have a thread problem (yikes!). My experience with threads and Tomcat
>is very minimal, but in my experience threads use a lot of memory. I believe they
>keep references to their entire call-stack (methods calling methods), and so when
>they hang a lot of references remain unavailable to the garbage collector. Don't
>worry about Tomcat: in my experience on this mailing list Tomcat's thread usage is
>perfect. It's always developers that mess up. Don't feel bad if this is the case.
>You only get good (err... marginally less dangerous) by screwing up several times. I
>almost took down a medium sized financial institution's website I was developing due
>to some shoddy thread work. Debugging multi-threaded apps when the threads go bad is
>fun in a way.
>
> The thing to remember with web applications is that each request, from start to
>finish, is going to need a thread. If the thread gets lost somewhere along the way,
>it's not coming back. Some tricks that seem to work for me (see what Tomcat-User
>thinks):
>
> Don't use wait() when you can use wait( 60000 )! At least you'll recover the thread
>a minute later.
>
> Don't use notify(). Use notifyAll() instead.
>
> In my opinion "wait(void)" and "notify()" are not meant for mortals. Especially not
>in conjunction with web applications.
>
>
> Good luck, ryan! Hopefully we can help you fix your website, and help Tomcat
>conquer the world!
>
> It would be a good idea to try and isolate your problem. Can you get the memory
>usage to balloon up during a simulation in a test environment? Of course, you're
>probably frantically trying to fix your production site... in which case banging out
>fear-inspired fixes can also work quite well, too.
>
> I do envy your close proximity to such a respectable load on your computer. I wish
>I could see what my own code would do at such use. My company plays it too safe to
>ever know: when the CPU hits 35% in top, they add a new computer to the cluster.
>
> yours,
>
> Julius
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Mon 12/2/2002 2:31 PM
> To: Julius Davies
> Cc: Tomcat Users List
> Subject: RE: Memory/Performance
> Thanks for replying I think you are on the right track i must not be doing
> something right here. You certainly got me confused and that can only be a
> step in the right direction. I have my session-timeout set to 15. My load
> is being generated from massive usage i get a million unique hits a month
> and have a lot of customers simultaneously logged in at once. Tomcat
> starts out with 128 megs and baloons up pretty quickly to 300 megs. It
> often exceeds that, there also seems to be a huge thread count.
>
> 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]>
