In my project, the RollingFileAppender was used with compression mechanism. Our application will generate lots of logs and then file rolling and compression will be triggered. We see the clear but slow trend of JVM's heap size increasement. By using the profiler tools to analysis the jvm memory, we saw there are lots of InfoStatus objects which keep increase with the number of file rolling.

By looking at the source code, I found that StatusManager will keep those status forever if no explicit clear action invoked by api. Meantime, Compressor class will addStatus for each compression action. Then there is no way to garbage collect those InfoStatus.

Below is the places where InfoStatus was created and added into StatusManager.

ch.qos.logback.core.rolling.helper.Compressor

public void compress(String nameOfFile2Compress, String nameOfCompressedFile) {
switch (compressionMode)

{ case GZ: addInfo("GZ compressing [" + nameOfFile2Compress + "]."); gzCompress(nameOfFile2Compress, nameOfCompressedFile); break; case ZIP: addInfo("ZIP compressing [" + nameOfFile2Compress + "]."); zipCompress(nameOfFile2Compress, nameOfCompressedFile); break; case NONE: throw new UnsupportedOperationException( "compress method called in NONE compression mode"); }

}

If above analysis is correct, then I believe this will be a memory issue and it is a critical one.