On Wednesday 21 July 2010, William A. Rowe Jr. wrote: > On 7/21/2010 4:35 PM, Stefan Fritsch wrote: > > And I agree that a unified logging formatter would be nice, but > > this is not something that will be done before 2.3.7 and it > > would likely mean an incompatible API change for modules > > providing handlers for mod_log_config. IMHO, this can wait until > > 3.0. > > IMHO, it must not. The simple reason is that the more code > duplication we introduce, the more opportunity for flaws and > maintenance headaches during the 2.4 lifecycle. I'd accept > waiting for this entire custom error log feature for 3.0, but > really would rather introduce it sooner and not later.
I fear a unified logging formatter may either delay 2.4 or not make it into 2.4. In 2.4, we really need some way to omit some of the fields we currently have in the error log prefix (> 100 chars of prefix is insane). But as I had less time in the last few days than I hoped, it does not look like my (non-unified) errorlog formatter would be ready for 2.3.7 in any case. So we will have time until 2.3.8 to decide what to do. > If there is a resulting API change, I think everyone is willing to > accept this during the 2.3-alpha/beta cycle. 2.4.0 is our > 'lockdown'. > > I'm willing to help with this code, although I'm just starting to > dig out of the hole from my two recent hand surgeries. 6-finger > typing isn't all that efficient :) I think there are more important things that could use your and my attention than avoiding this bit of code duplication. Buf if you want to start a bit of technical discussion: The main technical difference between error and access log is that for the access log, everything is allocated from the request pool and then written to the log file (i.e. there is no length limit). For the error log, there is a fixed 8K buffer (allocated on the stack). For the error log, it is not possible to use any of the existing pools to avoid unbounded memory usage. The unified log formatter would either have to use a pre-allocated buffer or a temp pool. For my work on the error log formatter, I have stayed with the pre- allocated buffer. Would this be a reasonable solution for the unified logger? It would mean a fixed limit for the access logs lines (though the access log could use a larger buffer than the error log, I guess 16 or 32K would be enough even for the access log). The pool approach would require a per-thread temp logging pool (using apr_threadkey_private_create or the like) or creating and destroying a sub-pool for every log line. Which solution looks better to you? Cheers, Stefan
