tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JACQUELINE Nicolas - REN ( NJacqueline@rennes.sema.slb.com )" <NJacquel...@rennes.sema.slb.com>
Subject Re: Servlet killing tracking
Date Wed, 24 Apr 2002 19:27:04 GMT


> 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?
>
The int and destroy procedures are vital because we create / destroy a
socket so that the servlet can connect to a remote server. Tomcat does not
re-init the servlet once he destroyed it. So that the connection with the
server is lost when tomcat kills the socket...

I think we're going to change the behaviour of our servlet so that it wont
do anything on destroy() and do what it actually does in destroy in a
special request, as you suggested.

>
> 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.
>
Rich idea, but we cant do this, because we cant simulate a sufficient number
of users and other technical problems (especially the server).

>
> cheers
> fillup
>
>
Thanks for your help,

Nicolas JACQUELINE






--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message