atom feed23 messages in org.apache.tomcat.devRe: AccessLogValve enhancement
FromSent OnAttachments
Mark ClaassenFeb 15, 2012 1:23 pm 
Mark ThomasFeb 15, 2012 1:32 pm 
Mark ClaassenFeb 15, 2012 1:55 pm 
Konstantin KolinkoFeb 15, 2012 2:06 pm 
Mark ClaassenFeb 16, 2012 7:16 am 
Mark ClaassenFeb 16, 2012 1:05 pm.zip
Konstantin KolinkoFeb 16, 2012 1:11 pm 
Mark ClaassenFeb 16, 2012 1:44 pm 
Filip Hanik - Dev ListsFeb 17, 2012 7:22 am 
Francis GaliegueFeb 17, 2012 7:54 am 
Filip Hanik - Dev ListsFeb 17, 2012 8:04 am 
Rainer JungFeb 17, 2012 8:13 am 
Christopher SchultzFeb 19, 2012 9:20 am 
Mark ThomasFeb 19, 2012 9:49 am 
Mark ClaassenFeb 19, 2012 6:53 pm 
Christopher SchultzFeb 21, 2012 8:37 am 
Mark ClaassenFeb 24, 2012 8:49 am 
Mark ClaassenMar 27, 2012 6:29 am 
Konstantin KolinkoMar 27, 2012 6:46 am 
Mark ClaassenMar 27, 2012 8:16 am 
Mark ClaassenMar 29, 2012 9:51 am 
Konstantin KolinkoMar 29, 2012 1:43 pm 
Mark ClaassenApr 11, 2012 11:09 am 
Subject:Re: AccessLogValve enhancement
From:Mark Claassen (mark@gmail.com)
Date:Mar 27, 2012 6:29:43 am
List:org.apache.tomcat.dev

Ok. I am back working on this again.

From the previous comments, I am not sure my efforts are going in the right direction. However, I have a working implementation that uses the standard logging mechanism now, while addressing some of the previous concerns.

I did a quick performance test, and it is true that the default mechanism is quite a bit faster than the standard JULI logger. For this test, I just modified the source code to write each log message 1000 times. The first set of timings (in millis) is from the current AccessLogValve, and the second set is using JULI.

AccessLogValve Elapsed Time: 8 AccessLogValve Elapsed Time: 19 AccessLogValve Elapsed Time: 63 AccessLogValve Elapsed Time: 6 AccessLogValve Elapsed Time: 7 AccessLogValve Elapsed Time: 8

INFO: AccessLogValve Elapsed Time: 830 INFO: AccessLogValve Elapsed Time: 1122 INFO: AccessLogValve Elapsed Time: 451 INFO: AccessLogValve Elapsed Time: 531 INFO: AccessLogValve Elapsed Time: 764 INFO: AccessLogValve Elapsed Time: 347

Granted, this certainly falls into the "Contrived micro-benchmark" realm. A real test would involve lots of threads each writing very little. Also, each thread would be doing a lot of other things, making the time spent in the access logger less significant. However, even in the worse case, it still only took a millis to write one message.

Honing my test case to test the speed of 1 single message (not just the write, but the whole process of creating and then writing the message), I got that it takes between 0 - 1 millis in the first case, and 0 - 2 millis with JULI. Most messages took 1 millis for each. (I have a pretty old machine I am testing on now.) I didn't test the speed of the file rolling and such. Also, I have no idea which would perform better under a heavy load.

I don't really have the facilities to do a realistic performance test. However, I think something can be gleaned from the above results. Does anyone have any advice or suggestions on what direction I should go? My main goal is to have automatic deletion of old log files. This is something I would imagine others would like as well, so I thought I would present here instead of just doing something myself. I certainly do not what to make anything more complicated to use / configure than it has to be.

I am considering 5 options: 1) I can add my "outputLoggerName" attribute, which will switch the valve to use the JULI logger 2) I can create some sort of AccessLogWriter that the AccessLogValves will delegate their writing to - With 2 implementations, one being the current method and one being a JULI implementation - Potentially removing one in the future if performance is not an issue. 3) I can just add an attribute to the AccessLogValves to automatically delete older files 4) I can just make my own private subclass to do what I want, and leave the tomcat code unaltered 5) Scrap the current file writing implementation in the AccessLogValve and go straight JULI

I would welcome any advice.

Thanks, Mark