[ http://jira.qos.ch/browse/LBCLASSIC-33?page=com.atlassian.jira.plugin.system... ] Ceki Gulcu edited comment on LBCLASSIC-33 at 11/7/08 3:45 PM: -------------------------------------------------------------- Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools. was (Author: noreply.ceki@qos.ch): Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools. Joern, After further investigation, I can see the previous instance of LoggerContext, created when the web-app is initialized, being finalized when the web-app is stopped. In practice, I have to invoke System.gc() from jconsole to provoke the garbage collection of the LoggerContext. As far as I can tell, the code in revision 1945 works well, as it should. Unfortunately, when I use the jmap/jhat tools for a very strange and unexplained reason, there still remains a reference to LoggerContext instance, which is extremely strange since I can guarantee that the only instance of LoggerContext created was garbage collected. I am attaching a copy of the jmap dump in case you'd like to have a look at it. At this stage, I am quite tempted to declare that the problem lies in jmap/jhat or alternatively my poor knowledge of those tools.
unregistering in the jmx plugin -------------------------------
Key: LBCLASSIC-33 URL: http://jira.qos.ch/browse/LBCLASSIC-33 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: unspecified Environment: Operating System: All Platform: All Reporter: Hontvári József Assignee: Ceki Gulcu
I started using the JMX plugin of login, and I wondered how should I shut it down when a web application is restarted. I haven't found a function which unregisters the Configurator MBean. This object holds a reference (through ContextAwareBase) to a Context. I am afraid that not unregistering it causes a memory leak when a web application is restarted. There should be a way to shutdown the JMX plugin. Or more generally an API to shut down the Logback system in its entirety: flush buffers, close files etc. It must be decided what to do if a log request arrives when or after logback is shutting down.
-- 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