Attaching a patch the implements what I have mentioned here. Also by default if the job-history-server configurations is not passed then jobhistory is served via the jobtracker webui.
By default we might continue to run this service in the same JVM as the jobtracker, so we don't force the maintenance of another daemon on every installation. Only folks who have huge clusters need configure things so that this is run as a separate process, potentially on a separate host.
This is what the attached patch does. Review?
So JobTracker.main() can check the configuration to see if it should, in addition to starting the jobtracker, start the job history service. In both cases, it should use independent ports from the jobtracker.
This is easy to do with the current patch. JobHistoryServer.java starts a webserver that serves the jobhistory jsps (i.e make jobhistory as the main context of the webserver) and can be invoked within the same jvm. But its simpler to add the jsp context to the current webserver which is done in this patch. Comments?
In general, it should be simple to run all of our daemons in a single JVM, or to mix-and-match them. This should require at most a custom main() routine per JVM. We use this kind of configuration for unit testing already.
This will require more refactoring and I feel should be done in a separate (unification) jira, thoughts?