Hmm, I'm running Tomcat 4.1.18 which didn't even support the %D logging
directive :-/
But now I have a load balancer in place, with one worker. A status is shown
below after about 6hrs of traffic.
As you can see the client errors make up about 6% of all incident traffic,
though they dwarf server errors.
Type Sticky Sessions Force Sticky Sessions Retries LB
Method Locking Recover Wait Time Max Reply Timeouts
lb True False 2 Request Optimistic 60 0
Good Degraded Bad/Stopped Busy Max Busy Next
Maintenance
1 0 0 18 60 37/99
Balancer Members
Name Type Host Addr Act State D F M
V Acc Err CE RE Wr Rd Busy Max Route
RR Cd Rs
worker41 ajp13 localhost:8009 127.0.0.1:8009 ACT OK
0 1 1 140 42245 97 2556 0 24M 1.4G
18 60 worker41 0/0
It certainly gives me a better picture of what's going on, but I'm no further
towards what is stopping everything working on a daily basis.
But then just as I'm writing this my site falls over - I get the Service
Temporarily Unavailable consistently on my pages. I grabbed a snapshot of the
status worker -
Type Sticky Sessions Force Sticky Sessions Retries LB
Method Locking Recover Wait Time Max Reply Timeouts
lb True False 2 Request Optimistic 60 0
Good Degraded Bad/Stopped Busy Max Busy Next
Maintenance
1 0 0 100 115 21/83
Balancer Members
Name Type Host Addr Act State D F M
V Acc Err CE RE Wr Rd Busy Max Route
RR Cd Rs
worker41 ajp13 localhost:8009 127.0.0.1:8009 ACT
ERR/FRC 0 1 1 132 43181 691 2597 0
24M 1.4G 100 115 worker41 0/0
Clearly there seemed to be some catastrophic occurrence that made the Error
count rocket and the worker state change. I'm unfamliar with the load balancer
- will a state of ERR/FRC be rectified somehow? For now I just restarted IIS &
Tomcat which appears to be the only method of recovery at present
cheers
Tim
________________________________
From: Rainer Jung [mailto:[EMAIL PROTECTED]
Sent: Mon 10/12/2007 15:39
To: Tomcat Users List
Cc: Ludwig,GJA,Graeme,DGE R
Subject: Re: ISAPI JK2 ran better than JK, how can that be?
Hi Tim,
[EMAIL PROTECTED] wrote:
> Hi Rainer,
>
> Thanks for the response. To cover a few points you made -
>
> - Yes, I had a hunch long running requests are a problem; because of
> our appliction design, some pages invoked for the first time take a
> while (we can't cache them all!). Is there an easy way to correlate
> (apart from timestamp) the errors in the isapi and the requests made
> to IIS ? I mean can I get isapi log to show the URL being processed?
I'm afraid the answer most liekely is "no". You can file an enhancement
request in our bugzilla. That way the feature might materialize one day.
For Apache httpd, correlation between error an log message is a little
better. Even though we don't include the URL, we include the PID and
thread ID, and both can be logged in the httpd access log. So having
time, process id and thread id, usually makes it possible to correlate
successful, although it is still some work and not perfect.
> - I've now got the %D option in place on Tomcat to figure out from
> tomorrow which are the heavy pages - Yes, thread dumps on JDK 1.3 &
> TC4.1.x are tricky - I'm looking at the Tomcat JavaWrapper approach
> as a way forward. The version of the 3rd party product we have in
> place is only supported on jdk1.3 (this is a pretty ancient set up!)
> - I agree that my incident traffic load is not huge, and should be
> supportable by the environment in place. - I'll try a load balancer
> worker to see if that tells me more info
At least it does tell you the number of errors a worker had, and also
the number of client errors. That way you can check quickly, if there
are more errors than client errors, and by pollling the values, you can
find out how often and during which times things are happening. Only
counters though, no per incodent information.
The page can be configured to return machine readable content. Have al
look at:
http://tomcat.apache.org/connectors-doc/reference/status.html
> If possible I'll have some more information in a day or so from
> this...
>
>
> cheers
>
>
> Tim
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
