[
https://issues.apache.org/jira/browse/HADOOP-16174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787924#comment-16787924
]
Andras Bokor commented on HADOOP-16174:
---------------------------------------
We do not want to preserve the ref outside of the switch case. Using a hard ref
to the logger keeps the object in memory while we reach SSL.java:196 which is
enough for us. We used local variable because we won't need that logger anymore
so the scope is kept as small as possible.
Another question is that should we set the log level back to INFO. Currently
there is no other logger message in SSL.java but setting back seems better and
seems a complete workaround excluding any possible side effect in the future.
[~denes.gerencser]?
[~vishwajeet.dusane], Denes' question seems reasonable. Why only one branch is
protected?
> Disable wildfly logs to the console
> -----------------------------------
>
> Key: HADOOP-16174
> URL: https://issues.apache.org/jira/browse/HADOOP-16174
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs/azure
> Reporter: Denes Gerencser
> Priority: Major
> Attachments: HADOOP-16174-001.patch
>
>
> We experience that the wildfly log
> {code:java}
> Mar 06, 2019 4:33:53 PM org.wildfly.openssl.SSL init
> INFO: WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2g 1 Mar 2016
> {code}
> (sometimes) appears on the console but it should never. Note: this is a
> consequence of HADOOP-15851.
> Our analysis shows the reason is that
> {code:java}
> java.util.logging.Logger.getLogger()
> {code}
> is not guaranteed to always return the _same_ logger instance so
> SSLSocketFactoryEx may set log level on different logger object than the one
> used by wildfly-openssl
> ([https://github.com/wildfly/wildfly-openssl/blob/ace72ba07d0c746b6eb46635f4a8b122846c47c8/java/src/main/java/org/wildfly/openssl/SSL.java#L196)].
> From javadoc of java.util.logging.Logger.getLogger:
> 'Note: The LogManager may only retain a weak reference to the newly created
> Logger. It is important to understand that a previously created Logger with
> the given name may be garbage collected at any time if there is no strong
> reference to the Logger. In particular, this means that two back-to-back
> calls like{{getLogger("MyLogger").log(...)}} may use different Logger objects
> named "MyLogger" if there is no strong reference to the Logger named
> "MyLogger" elsewhere in the program.'
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]