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:Feb 16, 2012 7:16:51 am
List:org.apache.tomcat.dev

Looking at the docs, it looks like the asynchronous parts of the logging mechanism are controlled through the logging configuration in either logging.properties or log4j.properties. I don't see any way to ensure that this is the case or to check to make sure the output is not going to the console.

That being said, this is just an option, and would hopefully be acceptable in many situations. I have not done tests to see the performance difference. Perhaps a strongly worded warning in the documentation would be sufficient to ensure people are smart about this?

Unless someone thinks that this change is unacceptable, I will continue my efforts and see what happens with it.

Thanks, Mark

On Wed, Feb 15, 2012 at 5:07 PM, Konstantin Kolinko <knst@gmail.com>wrote:

2012/2/16 Mark Claassen <mark@gmail.com>:

We would like to use the flexibility of the standard logging mechanism for the AccessLogValue. I could find no way to do this. Looking at the AccessLogValve code in Tomcat 7, it seems it would really would not be hard to add.

There already is standard logger in the AccessLogValve class, which is where error in the logger itself get routed. private static final Log log = LogFactory.getLog(AccessLogValve.class);

This still makes a lot of sense, and should probably be kept separate. What I would propose is that a new attribute be added, called maybe "systemLoggerName". If this is set, then the logger by that name would be used instead of the current hard-coded file logger. (Errors would still go to the statically defined Logger.)

I already tried this with the XML listed below and a slightly modified AccessLogValve and it seems to work perfectly. If this is something that would be considered a positive change, I would be happy to submit a patch and propose some documentation updates.

I am not exactly sure how this all works, especially since this is more of an enhancement rather than a bug fix. I sure there are guidelines for when in a release cycle these types of changes are appropriate.

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="log" prefix="localhost_access_log." systemLoggerName="mylogger" pattern="common" resolveHosts="false"/>

I would say that the performance requirements for the two are different. Access log should be fast and simple. The error log does not have to be as fast, as errors should be more rare.

The default JULI FileHandler is not suitable here. You have to configure buffers. You have to perform flushing. AccessLogValve wires to Tomcat's background processing, but IIRC you cann do flush via commons-logging wrapper. The only viable alternative here is AsyncFileHandler.

You should also make sure that the events wouldn't be printed to Console.

The ideas to extract some common code to elsewhere (e.g. time formatting cache) were spoken several times. They are feasible.

Regarding this "systemLoggerName" (or "logCategory" as I would name it) feature, I think it does not belong to the current AccessLogValve but you might plug it there after some refactoring.

Anyway I would like to see the whole picture, which includes the logging configuration that you would use with AccessLogValve.