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

Add new twitter event scriber impl #58

Merged
merged 6 commits into from
Dec 6, 2016

Conversation

dabaitu
Copy link

@dabaitu dabaitu commented Dec 2, 2016

Part 3 of 3 to upgrade to oss 0.157

@Yaliang
Copy link
Collaborator

Yaliang commented Dec 2, 2016

👍
Verified on devel.

Base64.getEncoder().encodeToString(serializer.get().serialize(thriftMessage)));
}
catch (TException e) {
log.warn(e, "Could not serialize thrift object" + thriftMessage);
Copy link
Collaborator

Choose a reason for hiding this comment

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

space after object

Does TBase have a human readable toString?

Copy link
Author

Choose a reason for hiding this comment

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

There's a json serializer, but I suspect that might encounter the same exception causing us to log it. I'm thinking of just not include the thriftMessage in the log, just have the exception.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I recommend logging a few key fields from thriftMessage that might be helpful when diagnosing exceptions.

}
}

protected boolean scribe(Optional<String> message)
Copy link
Collaborator

Choose a reason for hiding this comment

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

The return type is whether the message.isPresent(), which the caller already knows could this return void?

Also would it make sense to change this to take a String message and have the caller not make the call if it doesn't have one?

/**
* Class that scribes query completion events
*/
public class QueryCompletedEventScriber extends TwitterScriber
Copy link
Collaborator

Choose a reason for hiding this comment

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

Typically we want to favor composition over inheritance. What's the reasoning for using inheritance here? Seems like composition would work fine here.

Copy link
Author

Choose a reason for hiding this comment

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

You are right. The case for inheritance here is very weak, or bad. I was thinking QueryCompletedEventScriber is a TwitterScriber, but I wasn't thinking that the child is suppose to be a more limited version of the parent, which makes most sense to use composition. Will change.

@Override
public void queryCompleted(QueryCompletedEvent queryCompletedEvent)
{
log.info(Stringify.toString(queryCompletedEvent));
Copy link
Collaborator

Choose a reason for hiding this comment

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

There's a lot of code here to log the metadata that is mostly available to us in the UI for a given query. Do you expect we'll need to look up all of this info in the logs?

Copy link
Author

Choose a reason for hiding this comment

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

I don't. There's the raw json available in the new UIs too that has everything. For history we would look in the scribed dataset. How about I get rid of logging altogether?

Copy link
Collaborator

Choose a reason for hiding this comment

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

👍 to get rid of the detailed logging. Maybe we instead log a few key fields that might be useful?

Copy link
Author

Choose a reason for hiding this comment

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

earlier in the thrift serialization part logging a few key fields would tell us which query completion event failed to be serialized which is useful. Logging here is actually completely redundant because both the UI and scribe log have just as much info if not more, so I can't think of a reason we will ever look in the log for query specific info. Let's get rid of it! :)

public void queryCompleted(QueryCompletedEvent queryCompletedEvent)
{
log.info(Stringify.toString(queryCompletedEvent));
scriber.handle(queryCompletedEvent);
Copy link
Collaborator

Choose a reason for hiding this comment

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

can we scribe before logging so if there is an exception in the toString logic it won't effect the scribe?

{
private static final String DASH = "-";
private static final String FIELD_DELIMITER = " ,";
private static final String OBJECT_DELIMITER = "\n\t";
Copy link
Collaborator

Choose a reason for hiding this comment

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

inserting line breaks in logging messages is typically ill advised. It makes searching and grepping difficult because you don't get the entire log line. It also can potentially break log parses that expect messages of '[timestamp] [message]' for instance.

"principal(%s)",
"remoteClientAddress(%s)"};
return String.format(
String.format("QueryContext: %s", String.join(FIELD_DELIMITER, content)),
Copy link
Collaborator

Choose a reason for hiding this comment

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

By dynamically generating the String that's passed to String.format, we forgo the compile time checks that the format of the string matches the type and number of args passed, which is a common bug. I'd recommend not using an array to generate it dynamically and just inline it. It doesn't seem worth it just to share a comma as a delimiter.

return String.format("\nQueryCreatedEvent:\n\t%s\n", String.join(OBJECT_DELIMITER, content));
}

public static String toString(SplitCompletedEvent o)
Copy link
Collaborator

@billonahill billonahill Dec 2, 2016

Choose a reason for hiding this comment

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

if this necessary? why not just not log it.

@billonahill
Copy link
Collaborator

@dabaitu can you back out the mvn version upgrade? We should have separate PRs for upgrades that do not include feature changes.

Copy link
Collaborator

@billonahill billonahill left a comment

Choose a reason for hiding this comment

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

we should also revert the pom changes.

* Serialize a thrift object to bytes, compress, then encode as a base64 string.
* Throws TException
*/
public String serializeThriftToString(TBase thriftMessage) throws TException
Copy link
Collaborator

Choose a reason for hiding this comment

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

can this method be private?

}
}

public void scribe(String message)
Copy link
Collaborator

Choose a reason for hiding this comment

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

can this method be private?

*/
public class QueryCompletedEventScriber
{
private static String dash = "-";
Copy link
Collaborator

Choose a reason for hiding this comment

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

sounds be final and all caps.

return Base64.getEncoder().encodeToString(serializer.get().serialize(thriftMessage));
}

public void scribe(TBase thriftMessage, String origEventIdentifier)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of passing the exception log info in the signature, it would be cleaner to just have scribe throw TException and have QueryCompletedEventScriber catch it and handle the logging.

* Serialize a thrift object to bytes, compress, then encode as a base64 string.
* Throws TException
*/
private String serializeThriftToString(TBase thriftMessage) throws TException
Copy link
Collaborator

Choose a reason for hiding this comment

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

typically we put the constructor first before the methods, followed by public methods then private. would you shift these down please.

@@ -0,0 +1,78 @@
/*
Copy link
Collaborator

Choose a reason for hiding this comment

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

accidental commit?

Copy link
Author

Choose a reason for hiding this comment

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

:(, removed.

Copy link
Collaborator

@Yaliang Yaliang left a comment

Choose a reason for hiding this comment

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

Should remove "twitter-eventlistener-plugin/src/main/java/com/twitter/presto/plugin/eventlistener/:q"

Copy link
Collaborator

@billonahill billonahill left a comment

Choose a reason for hiding this comment

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

👍

@dabaitu
Copy link
Author

dabaitu commented Dec 6, 2016

verified all tests pass, and verified in devel with various different queries and checked twitter event listener is scribing the queries.

@dabaitu dabaitu merged commit a286397 into twitter-forks:twitter-master Dec 6, 2016
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.

3 participants