[
https://issues.apache.org/jira/browse/HDFS-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187470#comment-15187470
]
Bob Hansen commented on HDFS-9118:
----------------------------------
[~James Clampffer] - thanks for moving this forward. I would like to propose a
few changes to the implementation:
* Add a TRACE level for finer than Debug. My general mapping is
- ERROR: Something went wrong that is catastrophic (invalid internal states,
etc.)
- WARN: Something went wrong that you'll always want to know about, but
doesn't halt operations (recoverable errors, messages out of order, etc.)
- INFO: Here's a high-level list of what's going on with libhdfs++ (opening
and closing files, retrying operations, etc.)
- DEBUG: Here's a low-level stream of libhfds++ operations (operation by
operation)
- TRACE: Here's a packet-by-packet stream of libhdfs++ operations (function
entry/exit, each packet sent, etc.)
* Add a LogEnabled(level, component)-->bool function that can be checked before
constructing the LogMessage. This allows client code to circumvent expensive
logging operations. Make it pluggable so that we can hook it into the current
Google logging settings, etc.
* Most of the LogManager methods should be delegated to a logging plug-in:
- Make a streamlogger plug-in that spits the messages to a
stream/stdout/stderr
- Make a C API logger that supports the exposed C API. SetHook/ClearHook
should be part of that implementation
- EnableLogForComponent/DisableLogForComponent should be the domain of the
plug-in. LogEnabled(level,component) will ask the plug-in if we should log
this thing. Some plug-ins may want to disable certain components, others wont.
* Make the macros check LogEnabled first, and return a null-logging object that
will compile but no-op with all of the elements
* Logging should be disabled by default. This is a low-level library; it
shouldn't spew if not asked to
* logging.h should not depend on hdfs_ext.h; the C API should plug into the
logging to support the C glue
* Can we make the LogMessage a real ostream? That way consumers could do
LogMessage(...) << hex << my_pointer rather than LogHelpers::PointerToHex(...).
It's a bit more idiomatic, but I don't want to create a lot more work.
C API:
* Rather than require the consumers to call hdfsFreeLogData, always have the
library free the object. If the consumer wants to retain the data, they can
copy the structure. We could provide an hdfsCopyLogData method if we wanted to
be very nice
* Rather than have the logging hooks exposed in the LogManager, make a new
plug-in that is used by the C API that does the translation from C++-land to
the C API.
> Add logging system for libdhfs++
> --------------------------------
>
> Key: HDFS-9118
> URL: https://issues.apache.org/jira/browse/HDFS-9118
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Affects Versions: HDFS-8707
> Reporter: Bob Hansen
> Assignee: James Clampffer
> Attachments: HDFS-9118.HDFS-8707.000.patch,
> HDFS-9118.HDFS-8707.001.patch
>
>
> With HDFS-9505, we've starting logging data from libhdfs++. Consumers of the
> library are going to have their own logging infrastructure that we're going
> to want to provide data to.
> libhdfs++ should have a logging library that:
> * Is overridable and can provide sufficient information to work well with
> common C++ logging frameworks
> * Has a rational default implementation
> * Is performant
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
