JDK-4952316 : RFE: Can't "release" logger instances
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 6,7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2003-11-11
  • Updated: 2009-09-02
  • Resolved: 2009-09-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
Relates :  
Description
Name: rmT116609			Date: 11/11/2003


A DESCRIPTION OF THE REQUEST :
java.util.logging.LogManager is broken because it doesn't allow Logger's to be released (i.e. once loaded they are loaded forever).

This has two problems -
a) creation of lots of Loggers results in memory being lost that can never be reclaimed / released.
b) In an environment (like an application server) where apps get loaded and unloaded the java 1.4 Logger/LogManager API can be broken because an old instance of the logger is loaded and if you had a resource bundle sub-class associated with it you get a class cast exception when the logger is used again.


JUSTIFICATION :
Should be obvious from the description.
a) If you've finished with a logger you should be able to release it - knowing that there will be a cost re-acquiring it.

b) For App Servers.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
LogManager.removeLogger(String name) - deletes the cached instance of Logger for name and removes free the logging hierarchy.
ACTUAL -
Currently memory is lost and can't force a reload of bundles.

You can "trick" things by setting the locale to be a different value (which causes the resource bundle cache to reload) - but this is nasty and implementation dependant.

---------- BEGIN SOURCE ----------
// This will cause memory to be exhausted.
for (int i = 0; i < 10000000; i++) {
   Logger log = Logger.getLogger(new Object().toString());
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
There is no workaround to the memory problem (a).

for (b) you can "trick" things by setting the locale to be a different value (which causes the resource bundle cache to reload) - but this is nasty and implementation dependant.
(Incident Review ID: 225012) 
======================================================================

Comments
EVALUATION Bug 4952316 states the need for an API to remove a named logger from a LogManager object by mentioning the following in the "expected behavior" section: LogManager.removeLogger(String name) This bug also mentions another bug in another product that believes it needs a new API: 5066592 cacaoadm logging : undeploy module logger should be removed With the pair of fixes for 6274920 and 6498300, the original logging implementation has been fixed to use weak references between a LogManager object and a logger object. The fixes for 6274920 and 6498300 have been in JDK7 since JDK7-B12 and are in the process of being backported to the JDK6-Update train. A new API for removing a logger object from a LogManager object is not necessary now that 6274920 and 6498300 have been fixed. I am closing this bug as a duplicate of 6274920.
02-09-2009

EVALUATION This RFE looks very similar to the: 6274920 JDK logger holds strong reference to java.util.logging.Logger instances Fixing the following by RFE will help too: 4811930 RFE: Cannot remove Loggers from LogManager It is hard to decide which one of the three RFEs needs to be closed as a dup. Both RFEs above are going to be fixed in Dolphin, so this one will be fixed as well.
04-09-2006

SUGGESTED FIX Was marked 'fix in progress' but no suggested fix was provided. Changed to 'Defer'. ###@###.### 2005-05-02 21:47:01 GMT
02-05-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
24-07-2004

EVALUATION The current design obviously doesn't include this mechanism. There are some subtle dependencies so it looks like it may need to wait for the next feature release.
24-07-2004