Rüdiger Plüm wrote:
Or it likes to read many lines in one block as it can commit such things
as a batch rather than as single commits per line. Of course it is not required
to use DB transactions on mysql. But for Oracle this might improve performance.
but that would not be buffering in the sense that mod_log_config does
it. mod_log_config just keeps appending data to a buffer. in an sql
logger, to "buffer" you would keep a list/array/ring of log lines and
wrap them in a transaction. This cannot be "buffered" in mod_log_config
Hm, the question is how to get all the parameters set with the URL approach
(thinking
of piped loggers, which you said currently do not seem to work because of the
spaces).
See latest patch :)
Maybe as named parameters in the args?
If one likes to follow a filter approach I think URL's would not be useful, but
to be
honest I currently would have no other idea in this case as the shell approach
e.g.
Customlog "|monitor param=somevalue|buffer size=1024|compress |pipe /bin/foo"
combined
where the last member needs to be a backend provider like pipe, file, mysql.
interesting. You could have a "linebuffer" that buffered in a way I
describe above and a "buffer" that does it the current way. This may be
a larger change that we first started. Of course, you could define a
log filter chain:
LogFilter example "monitor param=somevalue|buffer size=1024|compress|file"
and then apply the filter in Custom Log:
CustomeLog filter://example/logs/some.log common
filter could supply "/logs/some.log" as user_data to each filter.
Of course, this is a much larger change than I think we are ready to
tackle now.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
