tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Morelock <>
Subject Re: Servlet killing tracking
Date Wed, 24 Apr 2002 19:10:30 GMT
fair enough.  some response questions in light of the new information you've

1) what exactly does your servlet depend on in int() and destroy() that is
so vital?
2) i asked this before but it probably wasn't clear:  does Tomcat never
re-init the servlet once it's been destroyed?  if it does not, i can see
that being an inescapable crash/problem.  if it does re-init it (thereby
hanging only one request or whatever) then can you get around it by
refactoring your design to minimize the impact of a destroy() call?

another suggestion i have would be to try to replicate the environment
precisely (since you seem to have a lot invested in this particular
configuration / architecture) on a network / machine that you have more
control over.  That way you can try to reproduce the problem and you'll have
better access to the debug data, ps -aux, etc.


On 4/24/02 11:17 AM, "JACQUELINE Nicolas - REN ( )" <> wrote:

>> 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.
> I understood what you ment, and I'm sure you're right. But as we're using
> Tomcat in a professional context, we cant change our Tomcat version without
> taking a big risk for our customer (we should validate again our
> application, that is expensive). That's why we're first trying to solve this
> problem before trying a newer version of Tomcat. But you seem to understand
> my point of view.
>> 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 dont give many information because I dont have that much ! When the
> application crashes, the customer sends us our logs that just say us the
> destroy method of our servlet was called by tomcat for no reason. The
> servlet is not crashed, the jvm is still running, apache still dispatchs
> requests to the servlet, but as it has been destroyed, we've lost all our
> data and the application crashes (exceptions in the jsps).
> But if the destory method is called sometimes for no reason, I think that
> we'll have to redesign the servlet, as you suggest :-7
>> 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).
> I'm really sorry if I'm not really clear, but in fact we have not a lot of
> information. But I'm going to try to be as precise as possible.
> So, more precisely (?) : our servlet runs fine, but Tomcat kills it
> sometimes for no reason (memory overflow ? tomcat bug ? ). I just want to
> know how I could track why Tomcat destroyed the servlet.
> I cant access the Tomcat platform (I cant run/stop Tomcat, ...), I can only
> access the servlet source code, tomcat configuration and logs.
>> cheers
>> phillip
> Thank you for your help,
> --
> To unsubscribe:   <>
> For additional commands: <>
> Troubles with the list: <>

To unsubscribe:   <>
For additional commands: <>
Troubles with the list: <>

View raw message