[logback-dev] [JIRA] Commented: (LBCORE-181) Memory issue caused by InfoStatus kept in StatusManager

hefeng cui (JIRA) noreply-jira at qos.ch
Wed Nov 17 07:23:51 CET 2010


    [ http://jira.qos.ch/browse/LBCORE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11896#action_11896 ] 

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

        


More information about the logback-dev mailing list