[ https://issues.apache.org/jira/browse/HADOOP-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666126#action_12666126 ]
Amar Kamat commented on HADOOP-5083: ------------------------------------ bq. Obviously, I'd like to see the new code integrated with HADOOP-3628. Could you use method names and a stub lifecycle that is compatible? +1. bq. the JobTracker should not be the place that starts an external JVM, as there are JVM options, console logs and other lifecycle issues to consider -such as keeping the JobHistory daemon live while the JobTracker restarts, yet still being able to log and terminate the JobHistory daemon when required. I have implemented #4 from the comment here [here|https://issues.apache.org/jira/browse/HADOOP-5083?focusedCommentId=12665708#action_12665708]. It simply adds the jsps to the current webserver of the jobtracker. No external JVMs are spawned from the jobtracker. Probably what Doug meant was to start another webserver in the same JVM that listens on another port. For now I felt its easy to simply add the jsps to the current webserver. bq. This is a really good opportunity to start HtmlUnit tests for the JSP pages, especially considering the amount of Java code embedded into them. Currently I am fixing the ant tests as jobs will be removed from the jobtracker as soon as they are done. I will start working on the test case for html/jsp as soon as this is done. Should the test case be addressed in a separate issue? Are there any security concerns in the proposed method or its implementation? I am looking into it too. > Optionally a separate daemon should serve JobHistory > ---------------------------------------------------- > > Key: HADOOP-5083 > URL: https://issues.apache.org/jira/browse/HADOOP-5083 > Project: Hadoop Core > Issue Type: Improvement > Components: mapred > Reporter: Arun C Murthy > Assignee: Amar Kamat > Attachments: HADOOP-5083-v1.2.patch > > > Currently the JobTracker serves the JobHistory to end-users off files > local-disk/hdfs. While running very large clusters with a large user-base > might result in lots of traffic for job-history which needlessly taxes the > JobTracker. The proposal is to have an optional daemon which handles serving > of job-history requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.