[JIRA] Created: (LBCLASSIC-172) Use WeakHashMap instead of Hashtable in LoggerContext
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 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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-172. ---------------------------------- Fix Version/s: unspecified Resolution: Won't Fix No, it's certainly not a bug, at least not one which can be adequately addressed by a WeakHashMap. This behavior allows loggers to be configured at init time and referenced later, which is an essential feature.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-172: --------------------------------------
This is IMHO a bug since nothing prevents me from using SLF4J that way. And I see no reason why WeakHashMap would be a problem, if I look at LoggerContext source.
Keep in mind that weak entries are only removed if a garbage-collection is performed. They *are* cached until GC. So even the relatively costly creation isn't a very valid argument.
The LoggerContext is a stateful object. If it creates a logger, say La, and configures it in some way, e.g. setting its level, we don't wish to have that state to disappear even if no one is referencing La.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-172: ----------------------------------------- What, exactly, is the difference between a Logger that is initially created and initialized when it is first requested (at a random time) using getLogger() and a Logger that is recreated after the previous one has been garbage collected? Is anything beside LoggerContext working on Logger configuration? I really don't see the problem, obviously...
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Thorbjoern Ravn Andersen commented on LBCLASSIC-172: ---------------------------------------------------- This is a memory leak, and should be treated as such. I agree with Jörn that the code should not fail. If a Logger is unused (note that static fields hold the instance infinitely) it should be able to be garbage collected. What is wrong with recreating a logger object if it has been disposed of, and needs to be reinstantiated?
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-172: -------------------------------------- A logger is a stateful object. For example, it may have zero or more children, it may have zero ore more appenders and it may have an assigned level. If it is garbage collected that state is lost, which would be quite unfortunate. Hopefully, this should settle the matter.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-172: ----------------------------------------- If a Logger has children then it isn't garbage-collected unless the children are unreachable, too, since Logger keeps a hard reference to its parent. I haven't found the configuration of the appenders just now. I assume loggers with appenders are created during init of LoggerContext. You could simply keep those loggers referenced in LoggerContext to prevent GC for those specific loggers, then.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-172: -------------------------------------- Don't forget the level.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-172: ----------------------------------------- Well, what about the level? If a Logger is created during LoggerContext init then it wouldn't be collected (if kept in e.g. a Set). This should cover both appender and level. I haven't taken a look at that code, yet, so I might really miss something. Result of the above code: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2760) at java.util.Arrays.copyOf(Arrays.java:2734) at java.util.ArrayList.ensureCapacity(ArrayList.java:167) at java.util.ArrayList.add(ArrayList.java:351) at ch.qos.logback.classic.Logger.createChildByName(Logger.java:392) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:148) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:48) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249)
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-172: --------------------------------------- In "normal" usage releasing loggers is a bad idea. First, it will result in some performance impact to the application. Since Loggers are usually associated with classes - and are often declared static to boot, "forgetting" them would cause all kinds of bad behaviors when a reconfiguration is performed.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-172: ----------------------------------------- A logger kept in a static field of a class would only get garbage-collected if said class (not it's instances) is garbage-collected, i.e. if the classloader that initially loaded that class is garbage-collected. A normal classloader keeps a hard reference to every loaded class. Some webapp classloader might handle this different to provide the ability to unload a webapp. WeakHashMap essentially works like a cache. References are only removed during garbage-collection, i.e. if memory is low anyway, and only if no hard reference preventing garbage-collection is left at that time. I guess that, in practice, there wouldn't be much difference and loggers wouldn't be recreated that often. We could check that by implementing a WeakHashMap ourselves which prints something when a reference is collected using a ReferenceQueue. The trick would be to keep hard references of any configured logger in LoggerContext. Upon reconfiguration those could be handled as necessary.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Holger Hoffstätte commented on LBCLASSIC-172: --------------------------------------------- This is a very interesting issue. Not sure if this matters any longer since it's already closed, but: - WeakHashMap is absolutely *not* like a cache since unused WeakReferences are cleared very aggressively even on minor collections, which happen pretty much all the time. If anything, SoftReferences are the right thing to use for caches that yield to memory pressure. The obvious downside is that this memory pressure is pretty arbitrary (softref pressure is a VM config option) and therefore also guaranteed to be inconvenient for someone, somehow. - WeakHashMap tries to expunge stale references on every get/put/contains, which will definitely impact logger lookup performance.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-172: -------------------------------------- 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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] 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@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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-172: ----------------------------------------- Oh dear, now I understand the problem. I wasn't aware that Loggers can be configured outside of LoggerContext. I've never done something like this. This makes the whole issue a lot more complexbthan I thought. It's solvable but rather complex - the state of a logger would need to be handled detached from the Logger itself. Urgs. I agree that this isn't simply an issue of WeakHashMap vs Hashtable. Solving this issue at *some* time should be kept in mind, though. Just for the sake of completeness: is there any other state beside level and appenders? And yes, Holger is right about SoftReferences.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn edited comment on LBCLASSIC-172 at 12/15/09 2:34 PM: ------------------------------------------------------------------- Oh dear, now I understand the problem. I wasn't aware that Loggers can be configured outside of LoggerContext. I've never done something like this. This makes the whole issue a lot more complex than I thought. It's solvable but rather complex - the state of a logger would need to be handled detached from the Logger itself. Urgs. I agree that this isn't simply an issue of WeakHashMap vs Hashtable. Solving this issue at *some* time should be kept in mind, though. Just for the sake of completeness: is there any other state beside level and appenders? And yes, Holger is right about SoftReferences. was (Author: jhuxhorn): Oh dear, now I understand the problem. I wasn't aware that Loggers can be configured outside of LoggerContext. I've never done something like this. This makes the whole issue a lot more complexbthan I thought. It's solvable but rather complex - the state of a logger would need to be handled detached from the Logger itself. Urgs. I agree that this isn't simply an issue of WeakHashMap vs Hashtable. Solving this issue at *some* time should be kept in mind, though. Just for the sake of completeness: is there any other state beside level and appenders? And yes, Holger is right about SoftReferences.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-172: -------------------------------------- The original test code takes ages before it throws an exception. this one gets there in a minute or two. public static void main(String[] args) { for (int i = 0; i < 10000000; i++) { LoggerFactory.getLogger("Foo." + (i%117)+"."+(i%19)+"."+(i%23)+"."+(i%13)+"."+i); if (i % 10000 == 0) { System.out.println("i=" + i); } } } Without tweaking the JVM, the above code stopped after creating 2.7Million loggers. Anyway, another thing to consider which makes it the whole issue really painful is that whenever the level of a logger is changed, the logger propagates this information to its child loggers. If you look at the code this results in nanosecond computational time for the evaluation of the effective logger level. However, when parent loggers reference their children, the children cannot be garbage collected. Unless of course the referencing is done using weak references. Frankly, making loggers garbage-collectible is not worth the effort, an effort which is pretty damn substantial and without necessarily clear cut advantages.
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
[ http://jira.qos.ch/browse/LBCLASSIC-172?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-172: ----------------------------------------- I seriously understand your objections, now, and I agree that this isn't something that can be changed easily. I guess it would be possible to work around all of those problems but this would definitely be a major amount of work, and a risky one. And yes, given that a logger keeps a reference to every child it wouldn't change anything if Hashtable was changed to WeakHashMap since the root logger won't be collected anyway and, therefore, no child. The reason why I submitted this as a bug was simply that it *is* a memory-leak - and I have generally a hard time to ignore such a thing ;) It saddens me a bit to know that it's there but there's nothing that can be done about it...
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
participants (5)
-
Ceki Gulcu (JIRA) -
Holger Hoffstätte (JIRA)
-
Joern Huxhorn (JIRA)
-
Ralph Goers (JIRA)
-
Thorbjoern Ravn Andersen (JIRA)