Hi Ralph,
thanks for answering. Your understanding is right and that is exactly what
I'm trying to do: to control in a separate way rolling over and compression
(the customer prefers to have some of the more recent files uncompressed).
Nevertheless, I would prefer to make all the management of
That's exactly my fear regarding mixing the framework with external tools.
This seems an issue related to buffering though.
I'm wondering if it would be possible to avoid any of these problems by
choosing date based rollover names. Let's say that I pick the following
setup:
- Trigger rollover
Hi Manuel,
If you're currently using Log4J 1.2 then you could also consider using the
TimeAndSizeRollingAppender, available from my site at www.simonsite.org.uk, as
a stop-gap before moving to Log4J 2.0.
Best Regards,
Simon
Sent from Yahoo Mail on Android
Hello all,
I'm evaluating a switch to log4j-2 since my application is required to
rollover files by age and size (for what the composite triggering policies
come handy). The rollover files shall also be compressed, but only those
reaching a given age.
What would be the preferred approach to
Log4j currently compresses the files when it rolls them over. Of course you can
cause that to happen based on time, but it sounds like you want the time of
rollover and time of compression to be separate. If so, I am not sure you
really need to tie the compression activity to Log4j, or at
It sounds like the delaycompress option from logrotate:
http://linux.die.net/man/8/logrotate
On 9 April 2014 09:46, Ralph Goers ralph.go...@dslextreme.com wrote:
Log4j currently compresses the files when it rolls them over. Of course
you can cause that to happen based on time, but it sounds
Be aware you can't combine the RandomAccessFile appenders with logrotate. See
https://issues.apache.org/jira/browse/LOG4J2-354
Sent from my iPhone
On 2014/04/10, at 7:58, Matt Sicker boa...@gmail.com wrote:
It sounds like the delaycompress option from logrotate:
