Thanks for these answers @Ralph : that was the kind of idea I had in mind : changing the RollingFileManager.asyncExecutor to be a ScheduledThreadPoolExecutor, and based on some configuration, submitting task to be executed after a random delay. However with this kind of approach, special treatment should be made if the manager is stopped with some pending delayed tasks in it.
@Matt : Cron policy can be a solution, but I don't know how to inject some random element in this to make the file roll at midnight + X random seconds. Since there is a lot of JVM to manage and some of them can be moved from a machine to another, I need to have a single log4j2.xml file for all environments. Moreover, our system administrators are reluctant to have something based on a shell-specific feature (such has the $RANDOM variable from bash) Anthony 2017-03-22 16:31 GMT+01:00 Ralph Goers <ralph.go...@dslextreme.com>: > These are separate JVMs, so having a single executor would be of no help. > > I believe the only way to do what you are asking for is to add > configuration so that the asynchronous thread has a semi-random delay when > it starts. > > Ralph > > > On Mar 22, 2017, at 7:58 AM, Greg Thomas <greg.d.tho...@gmail.com> > wrote: > > > >> One common issue we have with that framework (and I assume we can have > the > >> same with log4j2) is that all of our JVMs (we can have more than 50 > JVMs on > >> the same server in production) roll their file at midnight. > >> > >> When this happens, the system became often not usable for a few seconds > >> because of the simultaneous zipping of all the rolled files that > overload > >> the CPU (although zipping is done in a specific background thread). > > > > ISTR that with the most recent versions of log4j, these threads are in a > > thread pool so that they are properly shutdown at the right time. I > wonder > > if it's possible (or could be possible) to somehow inject a thread pool > in > > to log4j for this rollover, so that for you use case you could inject a > > single thread executor, so only one thread is ever compressing at a time. > > > > Just a thought, anyway, > > > > Greg > > > > On 22 March 2017 at 13:47, Anthony Maire <maire.anth...@gmail.com> > wrote: > > > >> Hi > >> > >> We are currently using another logging framework in production, but I'm > >> pushing to change it for log4j2. > >> > >> One common issue we have with that framework (and I assume we can have > the > >> same with log4j2) is that all of our JVMs (we can have more than 50 > JVMs on > >> the same server in production) roll their file at midnight. > >> > >> When this happens, the system became often not usable for a few seconds > >> because of the simultaneous zipping of all the rolled files that > overload > >> the CPU (although zipping is done in a specific background thread). To > >> reduce this effect, we are combining a time based rolling policy with a > >> sized based policy to zip smaller files, but this is not enough to make > the > >> system fully responsive at midnight. > >> > >> A pretty cool feature for us to avoid this issue is to have the > possibility > >> when a rolling is triggered because of a time based policy to change > file > >> immediately, but to wait for a random amount of time (within a > configurable > >> limit) before starting the compression. This random delay should help a > lot > >> to avoid contention on CPU cycles. > >> > >> Does log4j2 have something to solve this kind of issue ? If not, would > you > >> accept a pull request for this (I will open a Jira if needed) ? > >> > >> Regards, > >> Anthony > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
