Fix for LOGMGR-139

[dobozysaurus]

Took a look at LOGMGR-139, and I've got a simple implementation that I think will handle the majority of use cases.

The implementation adds a property, (pruneSize) on the PeriodicRotatingFileHandler. It defaults to zero. If it is set to > 0, it enables log pruning, which automatically removes old log files until some criteria is met. Pruning functionality operates on files in the directory of the current log file only, to a max depth of 1.

The prune size can be set to one of two options:

A long: Prunes files (oldest first) until the total size of pruneable files found <= pruneSize
An integer with a trailing 'P' or 'p': Prunes any log period files older than periods. Ex: "5p".

Files eligible for pruning have the following qualities:

• not the current log file
• regular (not directories, hidden, or symlinks)
• writable by the current executing user
• names that start with the current log name (so, if the current log name is "server.log", things like "server.log.foo", "server.log.2019-10-03", etc)

The implementation is simple; it doesn't handle edge cases like changed log directories. It's based on the assumption that the vast majority of users put their logs in one directory that they set once and very rarely change. I've added some tests as well. Hope that it is useful; let me know your thoughts!

[Hillrunner2008]

When I think about the other options at a configuration level that are currently available, I am really mostly attracted to leaving the PruningStrategy.PERIODS option, but this is great!

[jamezp]

Thank you for the contribution. I'll have to do some thinking on this as we haven't moved forward with this JIRA because of having to make assumptions about which files to remove.

What ever we do here would likely need to be ported to the PeriodicSizeRotatingFileHandler as well. That handler already has a maxBackupIndex property which could be confusing and add further complication if we add a prune property.

I personally have some reservations about a handler making assumptions on the files it deletes.

What I've got in a local branch is somewhat similar to this only it just used the maxBackupIndex and kept n days worth of files based on the last modified date.

[dobozysaurus]

Happy to help. Understood on the reservations about assumptions on files eligible for pruning. If we really want to avoid any and all false positives, one option: define an add an additional (required) property - eligibleForPruning - which can take a regex for files eligible to be pruned. Only files that match the regex and pass the other checks get pruned. It's another thing to configure and keep up to date, sure, but it would make the process safer.

[Hillrunner2008]

Could you lay out your reservations about the assumption around what files to remove? I read your comment on https://issues.jboss.org/browse/LOGMGR-139.

The advice that seems to have been given when this has come up in the past is to configure a cron job similar to this:

0 20 * * * find ${JBOSS_HOME}/standalone/log -type f -name server.log* -ctime +7 -exec rm {} \;

(see https://access.redhat.com/solutions/3682431)

I'm challenged to see a reason why similar behavior shouldn't be baked into the implementation with a new property (e.g. maxBackupPeriods) and some clear documentation around the delete behavior. Since this new property wouldn't need to have a default limit, it would be backwards compatible and only put the burden of reading about the cleanup behavior on those who choose to adjust their configuration to adopt the new feature.

I think to take extra care to match on the suffix with regex would be more challenging, but is also likely completely possible. I'm not sure its important to be that clever, but that is just my opinion.

[jamezp]

Hi @Hillrunner2008 I'm just a bit uncomfortable about assuming file names. If it's documented well I'd probably be okay with it. The other major part is performance. All logging to the handler will be blocked until the rotation is handled. Hopefully this wouldn't cause a huge performance impact, but it could so it needs to be well thought out.

I do realize cron is essentially doing the same thing, I'm just more comfortable with it because it's outside the server. It happens at a specific time and doesn't block the server.

A little OT, but another thought I've had is a define a separate FilePurger which is specific to JBoss Log Manager and just handles purging files on a schedule. I've got most of a cron parser complete when I was testing this, but I got sidetracked with other issues :) The main thing I like about this approach is it doesn't block logging from happening. It's just a separate thread that at a specified time just cleans up log files. Pretty much like cron though instead of the file name you give it a org.jboss.logmanager.handlers.FileHandler and maybe a few other things and it handles purging the files.