[jira] [Updated] (HDFS-10898) libhdfs++: Make log levels consistent
[ 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
[jira] [Updated] (HDFS-10898) libhdfs++: Make log levels consistent
[
https://issues.apache.org/jira/browse/HDFS-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Clampffer updated HDFS-10898:
---
Attachment: HDFS-10898.HDFS-8707.001.patch
[~bobhansen]
bq. What would you think of keeping SEEK and READ at the TRACE level since
consumers will tend to do those gazillions of times?
I'd prefer keep the interface consistent. The logger is pluggable so client
programs can always add something that adjusts the log levels the way they see
fit.
bq. We should move the async FileHandleImpl::PositionRead to DEBUG also.
Good catch, fixed with new patch.
bq. While we're here, can we make the INFO level message for Connect be more
human-readable ("Connecting to :"), perhaps with a DEBUG
level that includes debugging-appropriate data (this pointer, etc.). Have that
one only in the async version, so the consumer gets one INFO-level message per
connect. Not critical, but since whe're here...
I agree this would be nice to have. I went and narrowed the scope of this jira
so that those can be addressed later on. Similar things that could be improved
are how HA config info is logged during config parsing.
[~swalk...@yahoo.com] Thanks for the review. I added the minor adjustment for
PositionRead. If that change looks good to you and Bob I'll commit.
> 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
[jira] [Updated] (HDFS-10898) libhdfs++: Make log levels consistent
[ 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 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
