2011/1/14 Mark Thomas <ma...@apache.org>: > The fix for bug 50496 [1] (response sizes in access log valve ignored > compression) was implemented by forcing the response to be flushed all > the way to the socket so the access log valve can get an accurate byte > count from the connector. > > This has a number of consequences: > - chunked encoding will always be used for HTTP/1.1 requests > - the access log valve commits the response > > These consequences have triggered a couple a bugzilla reports [2], [3] > > While contemplating access logging it is also worth considering: > - additional enhancement requests - [4], [5] > - Tomcat and httpd support slightly different options for log patterns > - httpd logs the time the request was received, Tomact logs the time the > access log entry was written (this is a pain when trying to compare > httpd and Tomcat logs to diagnose proxy issues)
http://markmail.org/message/oiyuwo6z66quafzn Using o.a.coyote.Request#getStartTime() Anyway, if one wishes to align the logs, it might be better to use some id and not the time. > - the fixes to log 400 and other errors were relatively involved > - the access log ignores processing time before the request enters the > valve and after it leaves it > > > I can see a couple of ways forward: > a) provide minimal configuration changes (probably to control how bytes > are calculated) to address [2] & [3] > b) All of a) plus further changes to align Tomcat with httpd where possible > c) Refactor the access logging. I don't have a clear picture of what > this might look like but I am thinking along the lines of: > - log to JULI rather than manage files in the access log The log is buffered and AccessLogValve#backgroundProcess() flushes the log periodically. We should not loss that flushing. Other than that I do not really care how it is implemented. > - most of the code moves to the connector and gets triggered as part of > finishing the response The valve already implements AccessLog interface. If we can turn AccessLogValve#invoke() into noop (pass-through) and let the connector to provide us with logging via the #log(..) method, I think that won't break compatibility. > - access log valves register their desired log format etc with the > connector code when they start > - the access log valves add a marker to the request/response indicating > that it should be logged to their log file I do not quite understand this idea of "registering". That is to register that the access log "has seen" the request? (to avoid searching for it later?) > > Given that 7.0.6 is now stable, I think c) is probably too big a change > for 7.0.x but I do think that is the direction it needs to head. > > For 7.0.x, I think b) is probably the way to go along with some > additional documentation that explains the implications of each of the > configuration options from a). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
