We had a 'hung, and won't work without a reboot problem' and it was two things - we had to update some driver for the intel NIC cards in our server (for RedHat ES) and had to change some settings to get better NIC throughput.
Hope it helps. ----- Original Message ----- From: Steve Kirk <[EMAIL PROTECTED]> Date: Monday, November 8, 2004 4:19 pm Subject: RE: session-timeout means tomcat restart > Sorry for not replying sooner, I've been busy for a few days. > > Can you say more about the crashing? Any evidence from the logs? > A bit > difficult to be any more specific without more to go on really :) > > > However, I > > > have references to them from the controller so that shouldn't > be the > > > problem... eh? > > You mention "controller". Are you using TC as-is, or are you using a > framework such as struts or JSF by any chance? > > If you suspect that the problem is triggered by a closing session, > why not > try shortening the session timeout to a shorter length and see if > it crashes > quicker? In fact, it's worth checking whether the crash is around > the time > of the session expiry or not. If not, then your problem may not > be directly > caused by TC at all.....? > > Do you have any event listeners? If you have one for > sessionDestroyed/sessionWillPassivate, what does this code do? > > > -----Original Message----- > > From: Eric Wulff [EMAIL PROTECTED] > > Sent: Saturday 06 November 2004 00:51 > > To: Steve Kirk > > Cc: Tomcat Users List > > Subject: Re: session-timeout means tomcat restart > > > > > > 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 [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] > > > > > > > > ------------------------------------------------------------------- > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
