Re: Servlet killing tracking

[Neale Rudd]

Hi Jacqueline,

If your servlet is being destroyed, you can either do a
stack trace dump to the log file in your destroy() method...

new Exception().printStackTrace();

.. and then see which part of tomcat is killing the servlet,
or alternatively do something else (depending on the problems
caused by the servlet being destroyed and your specific
application requirements).

Having the servlet destroyed is a problem, but if you can't
upgrade to Tomcat 4, and the trace doesn't help, then maybe
you can create some workarounds so that the destroy()
doesn't affect the clients.

Best Regards,
Neale Rudd
metawerx
http://www.metawerx.net



- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, 25 April 2002 3:21
Subject: Re: Servlet killing tracking


> 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]>
> > > >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]>
>
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Re: Servlet killing tracking

[JACQUELINE Nicolas - REN ( [EMAIL PROTECTED] )]

> 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:   
For additional commands: 
Troubles with the list: 

Re: Servlet killing tracking

[Phillip Morelock]

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:   
> For additional commands: 
> Troubles with the list: 
> 


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Servlet killing tracking

[JACQUELINE Nicolas - REN ( [EMAIL PROTECTED] )]

>
> 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:   
For additional commands: 
Troubles with the list: 

Re: Servlet killing tracking

[Phillip Morelock]

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]>

Re: Servlet killing tracking

[JACQUELINE Nicolas - REN ( [EMAIL PROTECTED] )]

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]>
> > >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]>

RE: Servlet killing tracking

[Jay Gardner]

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]>
> >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]>

Re: Servlet killing tracking

[JACQUELINE Nicolas - REN ( [EMAIL PROTECTED] )]

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:   
> >For additional commands: 
> >Troubles with the list: 
> >
>
>
>
>
>

--
To unsubscribe:   
For additional commands: 
Troubles with the list: