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] [Commented] (HDFS-10898) libhdfs++: Make logs more informative and consistent
Date Mon, 03 Oct 2016 15:15:20 GMT

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

James Clampffer commented on HDFS-10898:
----------------------------------------

Looks like the CI failure is caused by the same assert that caused the first patch for HDFS-10931
to fail.  Once HDFS-10931 lands with the test fix I'll resubmit this patch and see if it's
cleared up, it passes in my docker environment locally.

> libhdfs++: Make logs more informative and 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
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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org


Mime
View raw message