i sent you one email already, but i will tell you this again, i have experienced many oddities in the servlet lifecycle with tomcat 3. 2.x. I strongly suggest you try (at least in a test environment) 3.3 or 4.x as in my experience these are much cleaner WRT the life cycle problems you're facing. I never looked into the oddities that much, because the upgrade stopped them.
you're also not really giving any information that would indicate how _you_ think this problem might be solved. You're saying, it's calling my destroy method, why? Questions for you: why does it matter? does tomcat then not re-init the servlet, thereby hanging all future requests to it? Or is that not good enough? does servlet.destroy() actually destroy something valuable? If that is the case, perhaps you should look into your own design and make certain that it is necessary to depend on this behavior, considering your unwillingness or inability to upgrade to a newer version (believe me i understand -- i currently have a high-traffic application deployed on 3.2.4, and its oddities WRT servlet lifecycle have caused me more than once to re-evaluate certain design choices). I'm not trying to be an ass here, but it just seems like you're asking for help but you're neither giving us enough information to help you nor are you apparently thinking critically about the problems before you (at least it's not apparent from your posts what steps you've already taken or what exactly your problem is with this behavior). cheers phillip At Wednesday, 24 April 2002, you wrote: >My problem is not a deadlock. My problem is that the service is running on >an other computer 100km from me, it runs 24 hours a day, and sometines >(rarely) it crashes because Tomcat killed the servlet. > >So I can only debug using logs this king of bug tracking. Using a debug tool >is not possible... > >Thanks for your help > >----- Original Message ----- >From: "Jay Gardner" <[EMAIL PROTECTED]> >To: "Tomcat Users List" <[EMAIL PROTECTED]>; ><[EMAIL PROTECTED]> >Sent: Wednesday, April 24, 2002 7:14 PM >Subject: RE: Servlet killing tracking > >> Hi, >> >> I don't have an answer for your deadlock?? Problem, but you might try >> downloading either Netbeans or Forte for Java. They have a debugger that >> works well for debugging servlets. They are both free and come with an >> integrated tomcat 3.2 container. With the debugger you may be able to >> validate whether you have an application deadlock. >> >> http://www.netbeans.org >> >> Best of luck, >> >> --Jay Gardner >> >> -----Original Message----- >> From: JACQUELINE Nicolas - REN ( [EMAIL PROTECTED] ) >> [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, April 24, 2002 10:44 AM >> To: Tomcat Users List >> Subject: Re: Servlet killing tracking >> >> I'm not using SingleThreadModel, and as I'm using Tomcat in a professional >> context, I cant upgrade to a newer version. That's why I need to track >what >> makes Tomcat destroy my servlet. >> >> Any idea ? >> >> > >> >> > it has been my experience that tomcat 3.2.x is pretty poor at managing >> > the servlet lifecycle generally. For instance, it does not respect >> > SingleThreadModel at all, and i've had other funkiness like you're >> > describing. >> > >> > I recommend you try a newer version of tomcat (as tomcat 4 is MUCH >> > higher throughput than 3). >> > >> > >> > >> > At Wednesday, 24 April 2002, you wrote: >> > >> > >Hi everybody, >> > > >> > >I'm using Tomcat 3.2.3 on a linux system to run a servlet-based >> > service. >> > >This application must support a high number of connected people (about >> > >1000). >> > > >> > >The service works fine, but sometimes Tomcat kills my servlet (calls >> > >Servlet.destroy) for no reason. How could I track why Tomcat killed my >> > >servlet ?! >> > > >> > >Thanks, >> > > >> > >Nicolas JACQUELINE >> > > >> > >-- >> > >To unsubscribe: <mailto:[EMAIL PROTECTED]. org> >> > >For additional commands: <mailto:[EMAIL PROTECTED]. org> >> > >Troubles with the list: <mailto:[EMAIL PROTECTED]. org> >> > > >> > >> > >> > >> > >> > >> >> -- >> To unsubscribe: <mailto:[EMAIL PROTECTED]> >> For additional commands: <mailto:[EMAIL PROTECTED]> >> Troubles with the list: <mailto:[EMAIL PROTECTED]> > >-- >To unsubscribe: <mailto:[EMAIL PROTECTED]> >For additional commands: <mailto:[EMAIL PROTECTED]> >Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
