-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-23381: Improve Logging in HBase Commons Package #913
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
💔 -1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM overall, but left a general question.
if (LOG.isInfoEnabled()) { | ||
LOG.info("Could not successfully schedule chore: " + chore.getName()); | ||
} | ||
LOG.info("Could not successfully schedule chore: " + chore.getName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you remove the check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use parameterized logging for the name. Also probably better to just pass the chore so we get the name and the desired period.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@HorizonNet The LOG.info
method will check internally if the log level is set to Info before emitting a log message, no need to do it twice. Since the log message is INFO level, it's almost certainly going to be enabled when running in production so it's not worth being too clever with regards to performance so I wouldn't normally bother making it parameterized if it's not already. However, I will make that adjustment since I'll emit the chore
object instead of its getName()
.
Also, this should be an ERROR level logging, to include the stack trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a good catch. This exception handling used to also be used as a non-error condition way of disabling the chore. agree that now it should probably call more attention to itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some feedback. Still reviewing
if (LOG.isInfoEnabled()) { | ||
LOG.info("Could not successfully schedule chore: " + chore.getName()); | ||
} | ||
LOG.info("Could not successfully schedule chore: " + chore.getName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use parameterized logging for the name. Also probably better to just pass the chore so we get the name and the desired period.
hbase-common/src/main/java/org/apache/hadoop/hbase/ChoreService.java
Outdated
Show resolved
Hide resolved
printChoreServiceDetails("requestCorePoolIncrease"); | ||
|
||
if (LOG.isTraceEnabled()) { | ||
LOG.trace("requestCorePoolIncrease"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not leave all of this in the method and have it do a proper trace guard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personal taste. It seems overkill to have a method just for logging. Nicer when I can just see the logging and move on with my life, not having to jump into a method. If that logging method was used 10 times and/or this method was heavily overloaded, I'd probably keep it, but for 2x, and some simple methods, it doesn't feel worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... it also gets confusing because folks need to know who is responsible for the logging guards... internal or external to the method. I've seen it done both ways and I've seen where people then don't include guards when they should or they double-bag it.
hbase-common/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java
Show resolved
Hide resolved
@@ -48,8 +46,6 @@ | |||
@InterfaceAudience.Private | |||
public class KeyValueUtil { | |||
|
|||
private static final Logger LOG = LoggerFactory.getLogger(KeyValueUtil.class); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll have to review where we call these utility methods since we're pulling out all this logging.
Please no one merge this util someone has done that check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. Thanks. This goes under the heading of 'log and throw'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's well and good in principle but only works if we actually log something about the exception when it's eventually caught. also depending on the severity it might be needed if we're at risk of stacktrace optimization by the JVM and log rolling making it so we can't actually get details from here when it comes time to log the exception elsewhere.
hbase-common/src/main/java/org/apache/hadoop/hbase/util/CommonFSUtils.java
Outdated
Show resolved
Hide resolved
hbase-common/src/main/java/org/apache/hadoop/hbase/util/CommonFSUtils.java
Outdated
Show resolved
Hide resolved
hbase-common/src/main/java/org/apache/hadoop/hbase/util/CommonFSUtils.java
Outdated
Show resolved
Hide resolved
hbase-common/src/main/java/org/apache/hadoop/hbase/util/CommonFSUtils.java
Outdated
Show resolved
Hide resolved
💔 -1 overall
This message was automatically generated. |
@busbey Made the requested changes. Just need your verdict on KeyValueUtil.java log-and-throw |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
4b4caae
to
09d1449
Compare
Sorry. I got all mixed up in my local repo. I ended up rebasing to squash my three commits and doing a force push. Sorry for the inconvenience. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
@busbey Want to give a blessing here sir? |
@saintstack @busbey Just merged in latest changes and fixed conflicts. Thanks! |
💔 -1 overall
This message was automatically generated. |
Is this one still active? |
No description provided.