Well, this is amazingly frustrating. My TC 5.0.28 running on Linux FC2 is completely crashing about every half hr when I have a webapp open and don't interact with it. I no longer have a time-out element in my web.xml so that doesn't seem to matter. TC shutdown and restart does not work. Instead, I'm required to hard boot my machine. I'm hung just trying to access the static welcome page of any app, although I do know that init() of the webapp I'm working on is being called.
Eric On Fri, 5 Nov 2004 15:43:28 -0800, Eric Wulff <[EMAIL PROTECTED]> wrote: > Linux FC2 > TC 5.0.28 > > I'm not storing a db object within a session although I am storing > objs within the session(of course - session.setAttribute). However, I > have references to them from the controller so that shouldn't be the > problem... eh? > > An interesting thing, I sometimes have to reboot my machine, not just > restart TC. Although other apps run fine, I have to reboot my machine > in order to get TC up again. > > I optimized my db connection, I did have it in servlet init(). > Although I knew I had to do this and I'm much better off for it, and I > appreciate you're noting it, but this didn't eliminate the crashing > problem. > > I also am now taking advantage of a connection pool. However, as you > figured, that does not solve the crash problem. > > Finally, I removed the <session-config><session-timeout> element from > myapp web.xml to test if this is the initiator of the problem. Let > you know what I find. Still, even if this is what initiates the > sequence leading to a crash, it shouldn't so something need be > fixed/optimized. Any other ideas? > > Eric > > > > > On Fri, 5 Nov 2004 13:03:27 -0000, Steve Kirk > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > -----Original Message----- > > > From: Eric Wulff [mailto:[EMAIL PROTECTED] > > > Sent: Friday 05 November 2004 07:01 > > > To: Tomcat Users List > > > Subject: session-timeout means tomcat restart > > > > > > > > > Hi, I'm experiencing 2 interesting problems that may be related to my > > > session timeout. > > > > > > 1. It seems that when my session times out I need to restart tomcat, > > > often just the application via reload in the manager, in order to gain > > > access to my db again. Could this be because I've been accessing the > > > db via jdbc hard coded in the servlet? Might using a datasource > > > connection pool take care of this? > > > > I would say that rather than the problem being JDBC hardcoded in the > > servlet, the problem is more likely to be _how_ that code is written. > > > > if it really is the session timeout that is causing this, it sounds to me > > like you are storing the database objects within a session object (which > > seems a bit unusual). or at least the last reference to them is stored > > there, so that when the session is destroyed, the database connection is > > lost. it might be better to store the objects in local variables within > > doPost if your servlet is simple, or if it's more complex, then perhaps > > better places to put them would be the servlet context, or a field of the > > servlet class/instance. it all depends on your particular situation. > > whichever you choose though, you must make sure that connections are closed > > (or returned to the pool) when you have finished with them. this generally > > involves careful use of try/catch/finally. > > > > if restarting the webapp fixes the problem, it could be that your database > > objects are initialised in the servlet init() method, which is then called > > again when the webapp restarts. but if this were the case then I'm not sure > > how session timeout could cause the problem that you describe. > > > > datasource connection pooling is not necessarily the answer. you can still > > use up all your database resources and/or leave them hanging whether you > > pool them or not! > > > > > 2. Often tomcat hangs without responding at all, to static or dynamic > > > requests, after it's been left for an hr or more with no interaction. > > > Might this be related to the memory leaks I hear about? > > > > you don't say which platform/ versions you are using so memory leaks are > > hard to comment on. IMHO the issues above are more likely to be the problem > > so check those first before suspecting an error in TC :) > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
