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

Tony History Server #62

Merged
merged 61 commits into from
Nov 9, 2018

Conversation

pdtran3k6
Copy link
Contributor

Added custom script for starting THS.
Refactored + Modularized code.

@pdtran3k6 pdtran3k6 self-assigned this Oct 30, 2018
@pdtran3k6 pdtran3k6 changed the title Phattran tony history server Tony History Server Oct 30, 2018
public Result index(String jobId) {
List<JobConfig> listOfConfigs = new ArrayList<>();
FileSystem myFs = getFs();
String tonyHistoryFolder = config.getString("tony.historyFolder");
Copy link
Member

Choose a reason for hiding this comment

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

make tony.historyFolder constant

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

yup

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm so in that case can I put Constants in utils?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, on a second thought, I don't think we should put it in Constants file, as tony.historyFolder is different for dev/prod mode.

Copy link
Contributor

@erwa erwa Nov 1, 2018

Choose a reason for hiding this comment

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

tony.historyFolder is the name of the parameter, which is constant. The actual value (which will be different in dev/prod) comes from the application.conf file (or later from $TONY_CONF_DIR/tony-site.xml).

Thus, I think tony.historyFolder can still be in the Constants class.

/**
* The class handles all HDFS file operations
*/
public class HdfsUtils {
Copy link
Member

Choose a reason for hiding this comment

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

this seems generic for all modules. We might need a component for all utils. Something like hadoop-common.

return localFileName;
}

static List<Path> getValidPaths(FileStatus[] lsJobDir, Predicate<FileStatus> fn) {
Copy link
Member

Choose a reason for hiding this comment

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

We need tests for methods in this class

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll look into how tests are written for a Play application and I'll add some soon.

Copy link
Contributor

Choose a reason for hiding this comment

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

These utility methods should be easy to test since you can just instantiate the input objects, directly call the methods, and then assert things about the returned output.

tony-history-server/app/utils/SecurityUtils.java Outdated Show resolved Hide resolved
tony-history-server/app/utils/SecurityUtils.java Outdated Show resolved Hide resolved
@erwa
Copy link
Contributor

erwa commented Nov 7, 2018

I think the two main things I'd like to see before we commit this are:

  • tests for the Utils classes
  • Javadoc for the Utils methods

@pdtran3k6
Copy link
Contributor Author

For dbc7615, I didn't write Javadoc for the last method, as me and @erwa discussed offline that it would be better to refactor the method to only be reading a specific file type (config file, which is always xml). Will update Javadoc after refactoring.

@@ -24,6 +25,12 @@
public class HdfsUtils {
private static final Logger.ALogger LOG = Logger.of(HdfsUtils.class);

/**
* Check to see if a HDFS path is valid.
Copy link
Contributor

Choose a reason for hiding this comment

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

Please define what "valid" means. It looks like this method just tests for path existence, in which case, why do we need this method? Why not just call fs.exists(filePath) directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're correct, but imo for the sake of code modularity, we should have the method. Calling fs.exists directly would require the try/catch block every time you call it, which makes the caller method more verbose than it should be.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I see. Avoiding try/catch blocks is a reasonable reason for adding this method.

Can we still update the description and replace is valid with exists? I think that's clearer. Also, I suggest renaming the method pathExists.

@@ -33,6 +40,12 @@ static boolean isPathValid(FileSystem fs, Path filePath) {
}
}

/**
* Retrieve the content of the file on HDFS.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you should mention as a string in the description.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Noted. Fixed: 610a368

@@ -48,13 +61,26 @@ static String contentOfHdfsFile(FileSystem fs, Path filePath) {
}
}

/**
* Return all paths that satisfy the <code>fn</code> predicate.
Copy link
Contributor

Choose a reason for hiding this comment

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

It doesn't make a difference here, but in general, {@code ...} is preferable to using <code>...</code> as {@code ...} lets you embed < and > without escaping them as &lt; and &gt;. Ref: https://stackoverflow.com/a/1671106/1128392

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was considering using backticks (`) to wrap the variable name in the doc, but I think I saw it somewhere where they use <code></code> as the variable's wrapper. Which one do you guys prefer? @erwa @oliverhu @hungj

Copy link
Contributor

Choose a reason for hiding this comment

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

Backticks is non-standard and won't cause the enclosed text to get rendered as monospace when Javadoc HTML is generated. Let's stick with {@code ...}.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Resolved: 63c80af

@erwa
Copy link
Contributor

erwa commented Nov 8, 2018

For dbc7615, I didn't write Javadoc for the last method, as me and @erwa discussed offline that it would be better to refactor the method to only be reading a specific file type (config file, which is always xml). Will update Javadoc after refactoring.

I think we don't need the method at all. We're designing the file naming conventions and folder layout, so we know what they are and can directly check for and read the expected files. (Also see my comment on HdfsUtils.java line 84.)

@oliverhu
Copy link
Member

oliverhu commented Nov 9, 2018

There has been 59 commits in this PR.. shall we clean up the existing and move forward with new features?

@pdtran3k6
Copy link
Contributor Author

@oliverhu 💯yeah I think so too... I'll make a new branch after merging this PR.

@erwa
Copy link
Contributor

erwa commented Nov 9, 2018

Yeah, I plan to review and hopefully commit this this afternoon.

Copy link
Contributor

@erwa erwa left a comment

Choose a reason for hiding this comment

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

Looks good. A few mostly minor comments that can be addressed in follow-up PRs. Merging this now.

@erwa
Copy link
Contributor

erwa commented Nov 9, 2018

Please do all new enhancements, feature work, and bug fixes in separate PRs (use a separate branch for each). Try to keep each PR focused on a single thing -- makes it easier to review and merge.

@pdtran3k6 pdtran3k6 deleted the phattran_tonyHistoryServer branch November 11, 2018 00:56
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

3 participants