[
https://issues.apache.org/jira/browse/HDFS-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189499#comment-15189499
]
James Clampffer commented on HDFS-9118:
---------------------------------------
bq. Great. If we can, let's implement the plugins for the C-API glue logger and
the stream/stderr logger. If we want to be super-cool, we could include example
plug-ins for google logging (but we don't want to have a dependency here).
I'm going to do the stderr + C api glue for now. I'll file a new jira for a
google logging plugin that we can keep in the examples directory to avoid
pulling too many third party bits into the core library. I think the stderr
and C interfaces should be somewhat special cases in that they should be able
to be turned on and off from the C API without doing any sort of rebuild.
At some point I'd also like to make a C++ plugin that can take pure C plugin
(struct of function pointers), mostly to keep as much parity between the C and
C++ interface, also because I really like jump tables.
bq. What data types to we need to support in the first pass? I would say all
the fundamental types http://en.cppreference.com/w/cpp/language/types and
special handling for const char * and const std::string &.
So for the first pass I'm thinking of supporting the following (some shortcuts
for brevity)
{code}
//using the widest (practical) type for integers so that any narrower integer
types can be widened and printed correctly
msg::operator<<(int64_t val)
msg::operator<<(uint64_t val)
//need to specialize for bool so it doesn't get converted to an integer type
and we can do nice "true"/"false"
msg::operator<<(bool)
//anything, except const char *, that can be coerced into void* gets printed as
hex. const char * gets it's own method to print as a string
msg::operator<<(void*)
//naturally strings, and const char* get printed as strings
msg::operator<<(const string&)
msg::operator<<(const string*)
msg::operator<<(const char*)
{code}
{code}
template<typename T>
msg::operator<<(const T& val) {
do something with std::to_string<T>(val)
}
{code}
I think this should only work for people who are statically linking the
library; in the dynamic library case the template instantiatiation is already
done so they don't benefit. I can go either way here; it's easy enough to add.
I think it's a small enough library that most people will be doing static
linkage but it might be odd for methods to stop working if the client changes
the build.
I was thinking more about this and I think a decent solution may be to add an
interface that looks like:
{code}
struct ExpensiveToSerialize {
virtual std::string ToLogString() = 0; //undefined behavior if
implementation has side effects!
}
{code}
This would allow us to hold on to a reference and only materialize the string
after the level and component checks have decided it's worth doing. Since
pruning is done on the same stack we don't need to worry about taking a
shared_ptr. This isn't an ideal solution because classes need to get some
boilerplate code or implement a operator(std::string)() to get around it, but
should let the dynamic library case work + cut down on string/stringstream
operations. I wasn't planning on including it in this JIRA though. Any
thoughts?
> 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)
