[
https://issues.apache.org/jira/browse/HDFS-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410450#comment-16410450
]
Hudson commented on HDFS-10898:
-------------------------------
SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #13869 (See
[https://builds.apache.org/job/Hadoop-trunk-Commit/13869/])
HDFS-10898: libhdfs++: Make log levels consistent. Contributed by James
(james.clampffer: rev 7ebecaeeded9ef6f0d9dff3e8994cf6eaad18920)
* (edit)
hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfspp/lib/fs/filehandle.cc
* (edit)
hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfspp/lib/fs/filesystem.cc
> libhdfs++: Make log levels consistent
> -------------------------------------
>
> Key: HDFS-10898
> URL: https://issues.apache.org/jira/browse/HDFS-10898
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: James Clampffer
> Assignee: James Clampffer
> Priority: Trivial
> Attachments: HDFS-10898.HDFS-8707.000.patch,
> HDFS-10898.HDFS-8707.001.patch
>
>
> Most of the public C++ FileHandle/FileSystem operations have a LOG_TRACE
> level message about parameters passed in etc. However many methods use
> LOG_DEBUG and a couple use LOG_INFO.
> We most likely want FS operations that happen a lot (read/open/seek/stat) to
> stick to LOG_DEBUG consistently and only use LOG_INFO for things like
> FileSystem::Connect or RpcConnection:: that don't get called often and are
> important enough to warrant showing up in the log. LOG_TRACE can be reserved
> for things happening deeper inside public methods and methods that aren't
> part of the public API.
> Related improvements that could be brought into this to avoid opening a ton
> of small Jiras:
> -Print the "this" pointer address in the log message to make it easier to
> correlate objects when there's concurrent work being done. This has been
> very helpful in the past but often got stripped out before patches went in.
> People just need be aware that operator new may eventually place an object of
> the same type at the same address sometime in the future.
> -For objects owned by other objects, but created on the fly, include a
> pointer back to the parent/creator object if that pointer is already being
> tracked (See the nested stucts in BlockReaderImpl).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
