The application.log is bascailly clean apart from all the errors
caused when the server crashes, and these are usually null pointer
errors. I've been working on this site for over 5 years now, and have
been emailing myself all errors for as long as i can remember.
Currently the 2 boxes combined are getting around 4 million pages a
week, so errors in the code get flushed out pretty quickly.
Server.log tells me when the service restarts, and the occasional
report of a long running request, ussually from the admin site. Theree
appears to be no link between the two.
Exception.log has the odd invalid email format, and a few "Could not
connect to SMTP host", but nothing that ties up with JRun barfng.
I suppose what you say about hammerring differnent areas under load
and narrowing it down could be the way to go, but if at the end of it
i find its a bug in JRun or the JRE then haven't i been doing someone
elses job for them?
Isn't there any other kind of logging, i could try?
I've got a few stackdumps taken after a crash which seem to be full of
self locked processes, but i'm not really sure what they mean. There
aree about 200 of these in one dump, where the "waiting on" and the
"locked" are the same, eg in the case below they're both "0x427cdf78".
Does that mean that thread is waitin on itself, or am i showing my not
inconsiderable ignorance?
"jrpp-378" prio=5 tid=0x096a0db0 nid=0xe60 in Object.wait() [65f4f000..65f4fdc0]
at java.lang.Object.wait(Native Method)
- waiting on <0x427cdf78> (a jrunx.scheduler.WorkerThread)
at jrunx.scheduler.ThreadPool$Throttle.enter(ThreadPool.java:130)
- locked <0x427cdf78> (a jrunx.scheduler.WorkerThread)
at
jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:454)
at
jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:295)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
Cheers
Bert
On Mon, 10 Jan 2005 10:14:36 -0800 (PST), Rob Rusher
<[EMAIL PROTECTED]> wrote:
> Bert,
>
> Start by making sure that your apps aren't producing any error entries in the
> logs files. Specifically, the application.log, exception.log and server.log.
> Start will with a clean set of log files to reduce the bulk so you can focus
> on
> what is happening.
>
> Once you know that app can run cleanly without producing errors, get a load
> tester. It doesn't matter which one; Segue SilkPerformer, Mercury LoadRunner,
> OpenSTA (free), Microsoft WAS Tool (free)
>
> If there is a problem with a piece of the application under load, the scripts
> you use to load test the application will help you narrow down the problem
> area.
>
> If there is a problem to be found, good debugging technique will help reveal
> the stealthy gremlin.
>
> Regards,
> Rob Rusher
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:10:5090
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/10
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:10
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.10
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
