hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Clampffer (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-10898) libhdfs++: Make log levels consistent
Date Wed, 05 Oct 2016 15:40:20 GMT

     [ https://issues.apache.org/jira/browse/HDFS-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

James Clampffer updated HDFS-10898:
    Summary: libhdfs++: Make log levels consistent  (was: libhdfs++: Make logs more informative
and consistent)

> 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
> 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
> -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

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

View raw message