Skip to content
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

Expose the request phase durations stored by RequestLog #100

Conversation

clayreimann
Copy link

  • Add FiliTimingFilter to allow applications to use custom logging filters while retaining the non-logging related behaviors of the BardLoggingFilter
  • Refactored the RequestLog by spinning the model out into a seperate class and marking the existing class as a utility

New methods

  • RequestLogUtils.startTimingRequest
  • RequestLogUtils.stopTimingRequest

@michael-mclawhorn
Copy link
Contributor

I'm pretty excited about this PR. I haven't had a chance to deep dive review in micro, but the broad strokes look very appealing.

private static final List<String> LOGINFO_ORDER = generateLogInfoOrder();

private static final ThreadLocal<RequestLog> RLOG = ThreadLocal.withInitial(RequestLog::new);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting way to do this. I wonder if SystemConfig should be tweaked in a similar way.

@michael-mclawhorn
Copy link
Contributor

michael-mclawhorn commented Dec 1, 2016

CHANGELOG definitely needs to be updated. Also, this will break every piece of downstream code, which won't make us many friends.

Well, any with logging.

@michael-mclawhorn
Copy link
Contributor

michael-mclawhorn commented Dec 8, 2016

@mangesh-pardeshi @codingwhatever
Could you guys give me an estimate of how many places you're calling RequestLog in your code? If the answer is very little, I'm inclined to let this change go through. If not, I'd like to know how much work this will produce for you.

@codingwhatever
Copy link
Collaborator

I can't find any uses in our code base.

@michael-mclawhorn
Copy link
Contributor

@clayreimann Could I request you to rebase this forward on master and see if you have any build errors. Out of band conversations look like this will have low impact on known adopters.

@clayreimann clayreimann force-pushed the extricate-timings-from-logging-filter branch 2 times, most recently from 92e0146 to eb37d13 Compare January 4, 2017 15:09
@clayreimann
Copy link
Author

@michael-mclawhorn @archolewa Rebased on master

Copy link
Contributor

@archolewa archolewa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, it looks pretty good. Looks like your editor's import settings don't quite line up with Fili's, so there's a bunch of imports that need to be fixed.

Also, I think we should move TimedPhase out into its own class, along with all the static methods from RequestLogUtils that manipulate timed phases. There's not really any point in having the TimedPhase be an inner class of RequestLog now that we've moved all of the stopwatch methods out of RequestLog.

@@ -2,10 +2,14 @@
// Licensed under the terms of the Apache license. Please see LICENSE.md file distributed with this work for terms.
package com.yahoo.bard.webservice.druid.client.impl;

import static com.yahoo.bard.webservice.web.ErrorMessageFormat.DRUID_URL_INVALID;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.REQUEST_WORKFLOW_TIMER;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.RESPONSE_WORKFLOW_TIMER;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the imports got a bit messed up. The static imports should remain up here, and the codahale and fasterxml imports should be moved back beneath the com.yahoo imports.

@@ -37,14 +32,17 @@
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.ws.rs.core.Response.Status;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the javax imports go after the java imports.

import static com.yahoo.bard.webservice.druid.client.impl.AsyncDruidWebServiceImpl.DRUID_QUERY_TIMER;
import static com.yahoo.bard.webservice.util.StreamUtils.not;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.REQUEST_WORKFLOW_TIMER;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.RESPONSE_WORKFLOW_TIMER;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, the imports got messed up. The static imports shuld remain at the top, and the com.codahale import should go back to where it was originally.

private final String name;
private long start;
private long duration;
protected static class TimedPhase {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're moving all of the stopwatch methods out of RequestLog, I think we should move TimedPhase out as well, since that's what the stopwatch methods are manipulating.

In fact, rather than having a RequestLogUtils class, I think we should have a TimedPhase class. That class has the definition of TimedPhase, along with all the static methods for manipulating them (i.e. starting, stopping, switching).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree, the stopwatch methods all operate in the context of the tread's RequestLog

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, erm, hmm. I actually have a PR out to address a separate issue that pulls the TimedPhase out: #143

Basically, to make starting and stopping timers cleaner, I had the TimedPhase implement auto-closeable, so that we could use Java's spiffy new try-with-resource block. But that required making the TimedPhase publicly available, and I'm not generally a fan of having public inner classes vs. just regular public classes. Don't really believe that they buy you much but code clutter.

import static com.yahoo.bard.webservice.logging.RequestLog.LOG_ID_KEY;
import static com.yahoo.bard.webservice.util.StreamUtils.not;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.REQUEST_WORKFLOW_TIMER;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.RESPONSE_WORKFLOW_TIMER;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports here are incorrect:

  1. static imports should go at the very top.
  2. Then com.yahoo in a separate paragraph
  3. Then com.* where * != yahoo in separate paragraph
  4. Then org.* in a separate paragraph
  5. Then java.*
  6. Then javax.*

@PreMatching
@Singleton
@Priority(1)
public class FiliTimingFilter implements ContainerResponseFilter, ContainerRequestFilter {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could really use a better name, since it isn't just doing timing (it's also stashing the request-id header). Maybe FiliInitializationFilter?

@@ -2,32 +2,30 @@
// Licensed under the terms of the Apache license. Please see LICENSE.md file distributed with this work for terms.
package com.yahoo.bard.webservice.web.handlers;

import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.REQUEST_WORKFLOW_TIMER;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.RESPONSE_WORKFLOW_TIMER;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -3,35 +3,33 @@
package com.yahoo.bard.webservice.web.handlers;


import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.REQUEST_WORKFLOW_TIMER;
import static com.yahoo.bard.webservice.web.handlers.workflow.DruidWorkflow.RESPONSE_WORKFLOW_TIMER;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -2,33 +2,31 @@
// Licensed under the terms of the Apache license. Please see LICENSE.md file distributed with this work for terms.
package com.yahoo.bard.webservice.web.handlers;

import static com.yahoo.bard.webservice.web.ErrorMessageFormat.EMPTY_INTERVAL_FORMAT;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -2,17 +2,16 @@
// Licensed under the terms of the Apache license. Please see LICENSE.md file distributed with this work for terms.
package com.yahoo.bard.webservice.web.responseprocessors;

import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.node.ArrayNode;
import com.fasterxml.jackson.databind.node.JsonNodeFactory;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clay Reimann added 2 commits January 26, 2017 17:06
* Add FiliTimingFilter to allow applications to use custom logging filters while retaining the non-logging
  related behaviors of the BardLoggingFilter
* Refactored the RequestLog by spinning the model out into a seperate class and marking the existing class
  as a utility
@clayreimann clayreimann force-pushed the extricate-timings-from-logging-filter branch from eb37d13 to 6a283a6 Compare January 26, 2017 23:38
@clayreimann
Copy link
Author

@michael-mclawhorn @archolewa Rebased again and addressed @archolewa's comments

Copy link
Contributor

@archolewa archolewa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a few minor comments, but nothing major. 👍 once they've been addressed.

}
LOG.warn("Exporting duration while timer is running. Measurement might be wrong: {}", phase.name);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can probably be simplified by using a positive conditional.

if (phase.isRunning()) 
{
   LOG.warn("Exporting duration while timer is running. Measurement might be wrong: {}", phase.name);
}

* Start the phase.
*/
protected void start() {
if (start != 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably replace start != 0 with isRunning().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants