I think this should be a 7.x change to avoid changing behavior too much on a minor release. Auto deleting old log files may be seen as non-passive.

Thoughts ?

Note that the 1GB limit would apply per log file.

Do you mean per appender (slowlog, json, etc), not per log file?

I would vote to bump to 30

Since we support date or size, which ever comes first... i would assume a (mostly) healthy system would typically hit the date based roll over first. (and I think we will get better then 50% on un-healthy systems)

@jordansissel, ah, yes. I meant per appender, not per log file. I'll edit the description.

@jakelandis, bumped to 30 files. I agree that we should get >50% compression in most cases.

I think this should be a 7.x change

I agree with your reasoning. Maybe for 6.x we can offer this as an alternative. Maybe ship a log4j2.properties.rotating or something that people can copy/paste or rename if they wish to use it?

I don't see any tests added, and maybe that's ok (log4j configs maybe are too complicated to write solid tests for, for this pr). Can someone run a manual test and verify the retention settings work as expected (max 30 files, daily rotation, rotation at 100mb) ?

Jenkins test this please

dan.hermann merged this into the following branches!