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

[hefeng cui (JIRA)]

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

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