[JIRA] Created: (LBCORE-181) Memory issue caused by InfoStatus kept in StatusManager
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
[ http://jira.qos.ch/browse/LBCORE-181?page=com.atlassian.jira.plugin.system.i... ] hefeng cui commented on LBCORE-181: ----------------------------------- One more comment, StatusManager has clear method but it can not be used to fix this issue since clear all the status will make logback work unproperly (at least in my test).
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
[ http://jira.qos.ch/browse/LBCORE-181?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-181: ----------------------------------- StatusManager references at most 300 messages. The first 150 and the last 150. See the BasicStatusManager class for details.
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
[ http://jira.qos.ch/browse/LBCORE-181?page=com.atlassian.jira.plugin.system.i... ] hefeng cui commented on LBCORE-181: ----------------------------------- Ok, then this won't be a issue. Please close it. Thanks for the explanation.
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
[ http://jira.qos.ch/browse/LBCORE-181?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu closed LBCORE-181. ----------------------------- Resolution: Incomplete
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
participants (2)
-
Ceki Gulcu (JIRA) -
hefeng cui (JIRA)