Thanks for the reply.
Even after reading documents I have some doubts.
1] How is a particular tomcat instance marked to "ERR" state?
This is what I understand. If apache is not able to connect to that tomcat
instance port ( typically when tomcat is not running) OR if it does not receive
reply from the tomcat instance. The second part is were I am not very clear. If
reply_timeout is not set then it waits indefinitely for the answer then how
does it mark it in state "ERR". If reply_timeout is set then it will wait for
that time for no. of retries and then mark it in state ERR. Is there any other
way a instance would get marked to state ERR?
2] Once instance is marked to state ERR then how does recovery options affect
it?
As per the document: "Recovery options influence, how we should handle retries,
in case we detect a problem with Tomcat. How often we will retry is controlled
by the attribute retries."
So, if for example I have recovery options set to 3 how would it work? If I
have set it to 7 how would it work?
I am trying to understand the details of all this so that I can get to the
bottom of the problem that I am facing. The problem that I am having is after
setting these timeouts I am seeing worse performance from the website There are
many website access errors reported.
Earlier the following was not set and now I have set ping_mode=A,
reply_timeout=60000, socket_connect_timeout=5000 and recovery_options=3.
Thanks,
Madhuri
--- On Tue, 8/4/09, Mark Thomas <ma...@apache.org> wrote:
> From: Mark Thomas <ma...@apache.org>
> Subject: Re: what exactly happens when timeouts are set and tomcat has
> outofmemory errors.
> To: "Tomcat Users List" <users@tomcat.apache.org>
> Date: Tuesday, August 4, 2009, 5:05 AM
> Madhuri Patwardhan wrote:
>
> > Do you know anything about recovery options?
>
> No. You could try reading the docs and/or the source code.
>
> Mark
> >
> > Thanks,
> > Madhuri
> >
> > --- On Mon, 8/3/09, Mark Thomas <ma...@apache.org>
> wrote:
> >
> >> From: Mark Thomas <ma...@apache.org>
> >> Subject: Re: what exactly happens when timeouts
> are set and tomcat has outofmemory errors.
> >> To: "Tomcat Users List" <users@tomcat.apache.org>
> >> Date: Monday, August 3, 2009, 6:49 PM
> >> Madhuri Patwardhan wrote:
> >>> Hi,
> >>>
> >>> Can somebody go over the details of what
> exactly
> >> happens when tomcat instance has outOfmemory
> errors and
> >> there are following timeouts set in a loadbalancer
> worker
> >> config.
> >>> This is my understanding.
> >>>
> >>> ping_mode=A, ping_timeout=10000,
> reply_timeout=60000
> >> and recorver_options=3
> >>> If the timeouts are set as above then
> CPing/Cpong test
> >> for connect and prepost will work. When a new real
> request
> >> is sent to this tomcat instance, it should hit
> reply_timeout
> >> because it has outofmemory errors.
> >>
> >> That depends on the state of the JVM. It might
> appear to
> >> work normally,
> >> it might fail to respond at all. Once on OOM has
> occurred
> >> Tomcat has to
> >> be assumed to be in an unknown state and should
> be
> >> restarted. I have
> >> seen Tomcat instances apparently recover from an
> OOM. It
> >> all depends why
> >> the OOM occurred and what Tomcat was doing at the
> time.
> >>
> >>> Then depending on no. of retries set (it is
> default,
> >> for me so 2), this instance will be tried once
> again. Second
> >> time also it should not get reply within
> reply_timeout and
> >> at that point it should be marked in "ERR" state.
>
> >>> However, I don't see that. I don't see it
> being marked
> >> in "ERR" state. The state is still "OK" inspite of
> this
> >> tomcat instance having outofmemory errors. Could
> somebody
> >> explain what am I missing?
> >>
> >> In short, you are incorrectly assuming that once
> an OOM has
> >> occurred
> >> Tomcat will no longer respond to requests.
> >>
> >> Mark
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
