actually tomcat spams a lot in the catalina.out, this is my favorite:
[EMAIL PROTECTED]: Exception Processing ErrorPa
ge[errorCode=404, location=/down/404.html]
ClientAbortException:  java.net.SocketException: Connection reset
        at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:331)
        at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:297)
        at org.apache.coyote.tomcat5.CoyoteResponse.flushBuffer(CoyoteResponse.j
ava:537)
        at org.apache.coyote.tomcat5.CoyoteResponseFacade.flushBuffer(CoyoteResp
onseFacade.java:238)
        at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.j
ava:303)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:147)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:104)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:117)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv
eContext.java:102)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:520)

(20 more lines and the page is actually there)

another cool log output: when you manage to throw an uncaught
exception in a jsp under some circumstances, each and every request
gets: response already commited with 30-40 lines of stacktraces. The
server itself dies in this scenario btw.

Also quite funny: configure tomcat to use 600 threads. Start on an old
linux distribution with 2.4.x kernel (no nptl). Start 600 test http1.1
threads. Watch the logfile.
(For even more fun watch the number of threads tomcat actually uses in
another window) :-)

But number one spammer in catalina.out are struts-taglibs!

regards
Leon



On 9/23/05, Tim Funk <[EMAIL PROTECTED]> wrote:
> See http://jakarta.apache.org/tomcat/faq/logging.html#catalina.out
>
> ClientAbortExceptions are thrown by tomcat when the client presses stop
> before the page is downloaded but does not log the exception. If there is
> custom code trapping exception - it might be logging it. In this case - the
> custom code is too agressive in catching exceptions and should let the
> container handle them correctly. (And probably incorrectly using
> error.printStackTrace() instead of a logger)
>
> -Tim
>
> [EMAIL PROTECTED] wrote:
>
> > How do you limit the size of Tomcats stdout file.
> >
> > If you look at version 5.5, the dialog for the service lets you put in
> > default or some path for the stdout file.
> >
> > But there is no option to set the limiting size or other parameters as you
> > would with log4j.
> >
> > This is the stdout log file which tomcat logs to if it gets something like a
> > network connection reset error.
> >
> > This is not really the applications log file per se.
> >
> > I tried asking this to the tomcat team via bugzilla and they were not
> > helpful.
> >
> > thanks
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to