hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roni Burd (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HADOOP-12956) Inevitable Log4j2 migration via slf4j
Date Wed, 21 Dec 2016 20:12:58 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15768054#comment-15768054
] 

Roni Burd edited comment on HADOOP-12956 at 12/21/16 8:12 PM:
--------------------------------------------------------------

Hi, I'm a ppal dev in MSFT and my team owns a massive YARN deployment. I was profiling our
latest production push and the log4j library takes a big chunk of processing time to the point
of even blocking other allocate() calls in YARM RM. (happy to send some traces if anyone is
interested) 

I was reading about the challenges in upgrading to log4j2 and how we are waiting for log4j2
2.7 for backward compat on the properties file. While the log4j guys are working on that,
was wondering if there is anything preventing us from making forward progress in parallel?
Also, I can see how this change could give a perf boost to older branches like 2.8 when running
at scale without major risk to destabilize functionality. 

I'm more than happy to help with patches as we might need this change for our scale anyways
and because we dont have strict compat issues that prevents us from moving now. Was really
looking for some guidance in order to contribute back (our team does regular contributions
so we know the process - but not on this specific area nor me personally)

Thanks!





was (Author: roniburd):
Hi, I'm a ppal dev in MSFT and my team owns a massive YARN deployment. I was profiling our
latest production push and the log4j library takes a big chunk of processing time to the point
of even blocking other allocate() calls in YARM RM. (happy to send some traces if anyone is
interested) 

I was reading about the challenges in upgrading to log4j2 and how we are waiting for log4j2
2.7 for backward compat on the properties file. While the log4j guys are working on that,
was wondering if there is anything preventing us from making forward progress in parallel?
Also, I can see how this change could give a perf boost to older branches like 2.8 when running
at scale without major risk to destabilize functionality. 

I'm more than happy to help with patches as we might need this change for our scale anyways
and because we dont have strict compat issues that prevents us from moving now. Was really
looking for some guidance in order to contribute back as this would be my first time (our
team has done contributions, but not me personally)

Thanks!




> Inevitable Log4j2 migration via slf4j
> -------------------------------------
>
>                 Key: HADOOP-12956
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12956
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Gopal V
>
> {{5 August 2015 --The Apache Logging Services™ Project Management Committee (PMC) has
announced that the Log4j™ 1.x logging framework has reached its end of life (EOL) and is
no longer officially supported.}}
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> A whole framework log4j2 upgrade has to be synchronized, partly for improved performance
brought about by log4j2.
> https://logging.apache.org/log4j/2.x/manual/async.html#Performance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message