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

Daniel Fuchs daniel.fuchs at oracle.com
Fri Nov 7 11:19:46 UTC 2014


On 05/11/14 19:47, Stanimir Simeonoff wrote:
>   945                     } catch (Exception ex) {
>   946                         System.err.println("Can't load log handler \"" + type + "\"");
>   947                         System.err.println("" + ex);
>   948                         ex.printStackTrace();
>   949                     }
>
> I'm not quite sure if handling Error (in particular any subclass of LinkageError) would make sense here (similar to the invocation of listeners).
> Of course there are other case handling just Exception and using word instead of 'type' but that's matter of another clean up.

Yes... LogManager should probably have some kind of ErrorManager - and
not just for listener invocation...

best regards,

-- daniel


>
> Stanimir
>
> On Wed, Nov 5, 2014 at 6:15 PM, Daniel Fuchs<daniel.fuchs at oracle.com  <mailto:daniel.fuchs at oracle.com>>  wrote:
>
>     Hi Mandy, Stanimir,
>
>     Here is the new webrev:
>     http://cr.openjdk.java.net/~__dfuchs/webrev_8060132/webrev.__03/index.html
>     <http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.03/index.html>
>
>     best regards,
>
>     -- daniel
>
>
>     On 05/11/14 12:47, Daniel Fuchs wrote:
>
>         On 04/11/14 23:40, Mandy Chung wrote:
>
>             On 11/4/14 8:48 AM, Daniel Fuchs wrote:
>
>                 Hi,
>
>                 Here is a revised patch that introduces a new
>                 <logger>.handlers.__ensureCloseOnReset=true|false
>                 property.
>
>             You have explored several different options and as you have
>             found,
>             none of them is ideal.  I think having a property to specify
>             ensureCloseOnReset would be reasonable to address the memory
>             leak
>             concern I have.
>
>             Would it be better to name it <logger>.handlers.__closeOnReset?
>
>
>         Well - closeOnReset is the normal behavior - if the logger
>         is still around. So I believe ensureCloseOnReset is a better name.
>
>             I am less sure if we need to have a global switch to revert
>             the default - do we expect the number of <logger>.handlers
>             is large? I would expect there would be small number.
>
>
>         I would expect the cases where you need to specify
>         ensureCloseOnReset will be rare. So maybe we should wait
>         until the case arises before implementing a global switch:
>         we can add that later if it's needed. The local switches
>         will provide a workable (even though possibly cumbersome)
>         work around.
>
>                 This property can be used as a fallback to turn the new
>                 behavior
>                 off in the improbable case where an application may need
>                 to do
>                 so. I have updated the LogManager class-level API
>                 documentation.
>
>                 http://cr.openjdk.java.net/~__dfuchs/webrev_8060132/webrev.__02/
>                 <http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.02/>
>
>             line 104-114: s/"true"/{@code true}
>             {@code reset} should be {@link ...} to the reset method (the
>             first occurrance)
>
>
>         Will do.
>
>             It doesn't seem necessary to specify "strongly referenced".
>             Maybe it's good to say "it will ensure the handlers associated
>             with the loggers will be closed at shutdown or at reset.
>
>
>         OK
>
>             If "closeOnReset is false", application should ensure the
>             handlers be closed before the logger gets garbage collected."
>
>
>         I will try to find something.
>
>             - something along that line.
>
>             typos:
>             186:  explicitely -> explicitly
>
>
>         I keep on doing this same mistake again and again :-(
>
>             Perhaps PersistentLogger can be renamed to CloseOnResetLogger
>             to make it clear what these loggers are kept for.  Similarly
>             for the variable name "persistentLogger" may be renamed too.
>
>
>         OK.
>
>
>             917: final might be adding noise
>
>         I like final ;-)
>
>             940: persitentLoggers
>
>         OK
>
>
>             line 917: you don't need (names.length == 0) to determine
>             the default,
>             right?  if names.length == 0, it wouldn't add to the
>             persistentLoggers
>             list
>             as no iteration in the for loop.
>
>
>         I will use the syntax that Stanimir suggested. It's much simpler
>         than what I originally wrote. If names.length == 0 we don't need to
>         look up the ensureCloseOnReset property.
>
>         Thanks Mandy,
>
>         I will send a new webrev shortly - with both yours & Stanimir
>         comments
>         integrated (barring the global switch - as we could do that in a
>         followup revision if that's really needed).
>
>         best regards,
>
>         -- daniel
>
>
>
>             Mandy
>
>
>
>




More information about the core-libs-dev mailing list