Oh, I forgot to clarify that the compression part of a rollover is done in a separate thread to reduce the latency impact. If you are worried about logging latency I recommend you use Async Loggers in which case a rollover will have no latency impact.
Remko On Wednesday, May 28, 2014, Remko Popma <[email protected]> wrote: > Hi David, > > I read the blog post you linked to. It seems that the author was very, > very upset that a utility called cp only uses a 512 byte buffer. He then > goes on to praise gzip for having a 32KB buffer. > So just based on your link, gzip is actually pretty good. > > That said, there are plans to improve the file rollover mechanism. These > plans are currently spread out over a number of Jira tickets. One existing > request is to delete archived log files that are older than some number of > days. (https://issues.apache.org/jira/browse/LOG4J2-656, > https://issues.apache.org/jira/browse/LOG4J2-524 ) > This could be extended to cover your request to keep M compressed files. > > I'm not sure about appending to existing gzip files. Why is this > desirable/What are you trying to accomplish with that? > > Sent from my iPhone > > On 2014/05/28, at 3:22, David Hoa > <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>> > wrote: > > hi Log4j Dev, > > I am interested in the log rollover and compression feature in log4j2. I > read the documentation online, and still have some questions. > > - gzipping large files has performance impact on latencies/cpu/file cache, > and there's a workaround for that using dd and direct i/o. Is it possible > to customize how log4j2 gzips files (or does log4j2 already do this)? See > this link for a description of the common problem. > > http://kevinclosson.wordpress.com/2007/02/23/standard-file-utilities-with-direct-io/ > > - is it possible to use the existing appenders to output directly to their > final gzipped files, maintain M of those gzipped files, and > rollover/maintain N of the uncompressed logs? I suspect that the > complicated part would be in JVM crash recovery/ application restart. Any > suggestions on how best to add/extend/customize support for this? > > > Thanks, > David > > >
