I think something like the following is possible
<RollingFileAppende filePattern=12:00:{date:seconds}>Means that you specify that the rollover should happen at 12:00 but the seconds are kind of randomized via Property Substitution or so. Not sure if date:seconds works but alternatively you could use system or env variables for it i guess. Br, David On Wed, Mar 22, 2017 at 3:18 PM, Matt Sicker <boa...@gmail.com> wrote: > I'm not sure if the feature is in log4j, but that reminds me of the jenkins > feature where you can do the same. I'd take a look at the cron triggering > policy docs first to see what's already possible. You can also combine that > with some scripts, so there's certainly a way to do it using current > functionality. > > On 22 March 2017 at 08: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 > > > > > > -- > Matt Sicker <boa...@gmail.com> >
