Memory issue caused by InfoStatus kept in StatusManager -------------------------------------------------------- Key: LBCORE-181 URL: http://jira.qos.ch/browse/LBCORE-181 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24, 0.9.25, 0.9.26 Environment: Linux, Reporter: hefeng cui Assignee: Logback dev list 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira