fair enough. some response questions in light of the new information you've provided:
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. cheers fillup On 4/24/02 11:17 AM, "JACQUELINE Nicolas - REN ( [EMAIL PROTECTED] )" <[EMAIL PROTECTED]> 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, > > > Nicolas JACQUELINE > > > > > > > -- > 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]>
