[
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.c...@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
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://qos.ch/mailman/listinfo/logback-dev
