RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed

[Jason Mehrens]

The strong reference is not changed to weak if later on all handlers are removed from the logger.



The only other solution I can think of to satisfy all of the previous pain points is to go back to keeping a reference to Logger.handlers in LogManager.LogNode and create a LogManager.orphanedHandlers map<String, COW>.  On dispose, if the handlers list is not empty, place it in the orphan handler map.  Every time we demand a Logger, remove the orphaned handlers list for that logger name and directly place the reference into the new logger.handlers.   Then the loggers can be GC'ed but the handlers can't.  On LogManager.reset walk the orphaned handlers map and close all handlers.  That fixes issues with same handler being added multiple loggers and allows weak references to the logger.


The new pain point of this is what do you do about loading the logger handlers from the config file if you have an orphan handler list.  Do you skip loading them or just add those plus the orphan list?


Jason

----------------------------------------
> Date: Fri, 24 Oct 2014 11:31:50 -0700
> From: mandy.chung at oracle.com
> To: daniel.fuchs at oracle.com; core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8060132: Handlers configured on abstract nodes in logging.properties are not always properly closed
>
>
> On 10/10/2014 8:39 AM, Daniel Fuchs wrote:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.01
>
> Sorry for the delay. I have been pondering if there is a better
> alternative and looks like you have considered a few other options that
> none of them is a good one.
>
> typos:
>
> 174 explicitely
> 925: persitentLoggers
>
> Is this only problem to the abstract node of Loggers (i.e. the ancestor
> is in the logging configuration but the library/app never creates such
> a logger)?
>
> Your patch will keep all loggers defined in the configuration strong
> reference. What if the application really wants the loggers say
> com.foo.FooLogger to get GC'ed (e.g. it wants the logger class and
> its defining class loader to be garbage collected) but the configuration
> does name com.foo.FooLogger.handler = ....
>
> Would that cause memory leak?
>
> Mandy