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

James Clampffer updated HDFS-10898:
-----------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

Thanks for the reviews [~bobhansen] and [~swalk...@yahoo.com].  Committed to 
HDFS-8707

> 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
(v6.3.4#6332)

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

Reply via email to