[
https://issues.apache.org/jira/browse/HIVE-25107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17343342#comment-17343342
]
Zoltan Matyus commented on HIVE-25107:
--------------------------------------
My intention back then was to keep roughly the same logging as before. Now,
having reviewed my change, I see that in one instance I effectively changed the
level from DEBUG to INFO (for tez/RecordProcessor.init). In all other cases,
{{tryLoggingClassPaths}} was added to replace two LOG.info calls (or two
l4j.info, etc).
So, at least for RecordProcessor.init, we definitely could change the level
back to DEBUG. But I think we might as well change the level to DEBUG in all
other cases as well, we don't need to stick to the previous behavior
necessarily. Let me know if you expect me to contribute to this.
> Thread classpath logging should be optional/DEBUG
> -------------------------------------------------
>
> Key: HIVE-25107
> URL: https://issues.apache.org/jira/browse/HIVE-25107
> Project: Hive
> Issue Type: Improvement
> Reporter: László Bodor
> Assignee: László Bodor
> Priority: Major
>
> This is since HIVE-21584
> I have a *72M* llap executor log file, then I grepped for only "thread class
> path", piped into a separate file and a result was a *22M* file...1/3-1/4 of
> the file was classpath info which is not usable for most of the time. This
> overwhelming amount of classpath info is not needed, assuming that classpath
> issues are reproducible with more or less effort, user should be responsible
> for turning on this expensive logging on demand. Not to mention performance
> implications which cannot be ignored beyond a certain amount of log messages.
> https://github.com/apache/hive/commit/a234475faa2cab2606f2a74eb9ca071f006998e2#diff-44b2ff3a3c4a6cfcaed0fcb40b74031844f8586e40a6f8261637e5ebcd558b73R4577
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
