Memory consumption problem with LRUMessageCache class
Hello, we have problems of excessive memory consumption, due to the object LRUMessageCache that grows constantly, until it exceeds 100MB. Then we restart the JVM to avoid crashes. Could the anomaly http://jira.qos.ch/browse/LBCLASSIC-255 regarding the fact that the class LRUMessageCache is not multithread-safe explain the problem? Thank you in advance.
On 12.04.2011 11:45, François Petitit wrote:
Hello,
we have problems of excessive memory consumption, due to the object LRUMessageCache that grows constantly, until it exceeds 100MB. Then we restart the JVM to avoid crashes.
Could the anomaly http://jira.qos.ch/browse/LBCLASSIC-255regarding the fact that the class LRUMessageCache is not multithread-safe explain the problem?
Thank you in advance.
Hello Francois, What you describe sounds like a serious bug. Could you please enter a bug report so that the bug is not fotgotten? Interestingly enough, LRUMessageCache is based for the most part on the JDK's LinkedHashMap. If the bug is located in LRUMessageCache in the code extending LinkedHashMap then we will fix LRUMessageCache. If however, the bug is in LinkedHashMap, which is a distinct possibility, then we can revert to the original LRUMessageCache which implemented the functionality from the ground up, without relying on LinkedHashMap. In any case, please enter a bug report indicating your version of logback and JDK. Cheers, -- Ceki QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software engineers. For further details, see http://logback.qos.ch/job.html
Hello, thanks a lot for your quick answer. I just created http://jira.qos.ch/browse/LBCLASSIC-262 , please ask me for any details. Because we use a very old version of IBM JVM, I looked at the IBM JVM fixes, searching something about LinkedHashMap, but didn't find anything. Do you have already planned a new release of Logback (0.9.29), including the patch for LBCLASSIC-255? Thanks, François Petitit 2011/4/12 Ceki Gulcu <ceki@qos.ch>
On 12.04.2011 11:45, François Petitit wrote:
Hello,
we have problems of excessive memory consumption, due to the object LRUMessageCache that grows constantly, until it exceeds 100MB. Then we restart the JVM to avoid crashes.
Could the anomaly http://jira.qos.ch/browse/LBCLASSIC-255regarding the
fact that the class LRUMessageCache is not multithread-safe explain the problem?
Thank you in advance.
Hello Francois,
What you describe sounds like a serious bug. Could you please enter a bug report so that the bug is not fotgotten?
Interestingly enough, LRUMessageCache is based for the most part on the JDK's LinkedHashMap. If the bug is located in LRUMessageCache in the code extending LinkedHashMap then we will fix LRUMessageCache. If however, the bug is in LinkedHashMap, which is a distinct possibility, then we can revert to the original LRUMessageCache which implemented the functionality from the ground up, without relying on LinkedHashMap.
In any case, please enter a bug report indicating your version of logback and JDK.
Cheers,
-- Ceki
QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software engineers. For further details, see http://logback.qos.ch/job.html _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
I'd also really appreciate a 0.9.29 release if there are no show-stoppers at the moment. Mainly because of LBCLASSIC-246 but also because of LBCLASSIC-257 & LBACCESS-12. I thought that LBCLASSIC-259 was just a duplicate of LBCLASSIC-246 but I may have been mistaken. LBCLASSIC-246 is rather annoying since it garbles up the output of several console applications in our company right now... Cheers, Joern. On 12.04.2011, at 18:05, François Petitit wrote:
Hello,
thanks a lot for your quick answer.
I just created http://jira.qos.ch/browse/LBCLASSIC-262 , please ask me for any details. Because we use a very old version of IBM JVM, I looked at the IBM JVM fixes, searching something about LinkedHashMap, but didn't find anything.
Do you have already planned a new release of Logback (0.9.29), including the patch for LBCLASSIC-255?
Thanks,
François Petitit
2011/4/12 Ceki Gulcu <ceki@qos.ch> On 12.04.2011 11:45, François Petitit wrote: Hello,
we have problems of excessive memory consumption, due to the object LRUMessageCache that grows constantly, until it exceeds 100MB. Then we restart the JVM to avoid crashes.
Could the anomaly http://jira.qos.ch/browse/LBCLASSIC-255regarding the
fact that the class LRUMessageCache is not multithread-safe explain the problem?
Thank you in advance.
Hello Francois,
What you describe sounds like a serious bug. Could you please enter a bug report so that the bug is not fotgotten?
Interestingly enough, LRUMessageCache is based for the most part on the JDK's LinkedHashMap. If the bug is located in LRUMessageCache in the code extending LinkedHashMap then we will fix LRUMessageCache. If however, the bug is in LinkedHashMap, which is a distinct possibility, then we can revert to the original LRUMessageCache which implemented the functionality from the ground up, without relying on LinkedHashMap.
In any case, please enter a bug report indicating your version of logback and JDK.
Cheers,
-- Ceki
QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software engineers. For further details, see http://logback.qos.ch/job.html _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
participants (3)
-
Ceki Gulcu -
François Petitit -
Joern Huxhorn