[
https://issues.apache.org/jira/browse/HADOOP-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715088#action_12715088
]
Todd Lipcon commented on HADOOP-4383:
-------------------------------------
Hey Steve,
I see this and the service lifecycle interface as orthogonal tasks. Making
services extend an interface is important if you want to use some sort of
Java-based container to handle cluster lifecycle management (the "choreography
of booting" as you nicely described it). There are some people, however, who
already do this choreography using some different external (non-Java) tools
where that common Java interface is unnecessary (for example, using unix tools
to manage the services via init scripts).
Regarding the J2EE pattern, I think Jeff was just pointing it out as an example
of this pattern that we should look to for inspiration rather than suggesting
any actual integration of parts of the J2EE stack.
-Todd
> Add standard interface/methods for all services to query IPC and HTTP
> addresses and ports
> -----------------------------------------------------------------------------------------
>
> Key: HADOOP-4383
> URL: https://issues.apache.org/jira/browse/HADOOP-4383
> Project: Hadoop Core
> Issue Type: Improvement
> Components: dfs, mapred
> Affects Versions: 0.20.0
> Reporter: Steve Loughran
> Priority: Minor
>
> This is something I've ended up doing in subclasses of all the services:
> methods to get at the IPC and HTTP port and addresses. Some services have
> exported methods for this (JobTracker), others package-private member
> variables (namenode), while others don't allow you to get at all the data
> (Datanode keeps the http server private).
> A uniform way to query any service for its live port and address values make
> some aspects of service management much easier, such as feeding those values
> in to http page monitoring tools.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
