[logback-dev] [JIRA] Issue Comment Edited: (LBCLASSIC-172) Use WeakHashMap instead of Hashtable in LoggerContext

Ceki Gulcu (JIRA) noreply-jira at qos.ch
Tue Dec 15 14:15:33 CET 2009


    [ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11461#action_11461 ] 

Ceki Gulcu edited comment on LBCLASSIC-172 at 12/15/09 2:14 PM:
----------------------------------------------------------------

Any approach which strives to diminish the memory impact of logback loggers, has to take into account and preserve  the following property.

 {
   Logger l = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("x");
   l.setLevel(Level.INFO);
}

an arbitrary amount of time later

 {
   Logger l = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("x");
   assert l.getLevel() == Level.INFO; // must hold true assuming l's level has not been changed
}

Level preservation extends by analogy to other logger properties such as appenders.

The only correct way to limit memory impact of loggers while still maintaining correct state, is to recognize that while loggers are stateful objects, for the majority of loggers that state is null. A logger tree is much a like a sparse matrix, with many elements holding the value 0 while only a small minority holding non-zero values.

It's quite a difficult problem and one which is unlikely to be solved by just changing the hash table type.

      was (Author: noreply.ceki at qos.ch):
    Any approach which strives to diminish the memory impact of logback, has to take into account and preserve  the following property.

 {
   Logger l = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("x");
   l.setLevel(Level.INFO);
}

an arbitrary amount of time later

 {
   Logger l = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("x");
   assert l.getLevel() == Level.INFO; // must hold true assuming l's level has not been changed
}

Level preservation extends by analogy to other logger properties such as appenders.

The only correct way to limit memory impact of loggers while still maintaining correct state, is to recognize that while loggers are stateful objects, for the majority of loggers that state is null. A logger tree is much a like a sparse matrix, with many elements holding the value 0 while only a small minority holding non-zero values.

It's quite a difficult problem and one which is unlikely to be solved by just changing the hash table type.
  
> Use WeakHashMap instead of Hashtable in LoggerContext
> -----------------------------------------------------
>
>                 Key: LBCLASSIC-172
>                 URL: http://jira.qos.ch/browse/LBCLASSIC-172
>             Project: logback-classic
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 0.9.18
>            Reporter: Joern Huxhorn
>            Assignee: Logback dev list
>             Fix For: unspecified
>
>
> Preventing garbage-collection of unused Loggers is a bad idea. 
> The following code should not fail:
> for(int i=0;i<10000000;i++) {
>   LoggerFactory.getLogger("Foo."+i).debug("Foo!");
> }

-- 
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