[
https://issues.apache.org/jira/browse/YARN-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742633#comment-13742633
]
Steve Loughran commented on YARN-1075:
--------------------------------------
Karthik,
Both the named services extend {{AbstractService}}, whose {{serviceStart()}}
method is a no-op; you could delete the superclass invocations in both methods
and it would do nothing: all the service state management logic is now in
{{AbstractService.start()}} and {{AbstractService.stop()}}, which shouldn't be
subclassed (the only reason they aren't final is that some mocking tests like
to override these methods)
When I moved to the new service APIs in YARN-117 I didn't reorder things here
on in service stop, on the assumption that the code knew what it was doing -and
left the calls to the superclass in just to remind others building services
that it is wise to relay up, even if the default class is empty.
> AsyncDispatcher and ResourceTrackerService violate serviceStart() semantics
> ---------------------------------------------------------------------------
>
> Key: YARN-1075
> URL: https://issues.apache.org/jira/browse/YARN-1075
> Project: Hadoop YARN
> Issue Type: Bug
> Affects Versions: 2.1.0-beta
> Reporter: Karthik Kambatla
> Assignee: Karthik Kambatla
> Attachments: yarn-1075-1.patch
>
>
> IIUC, the serviceStart() implementation of services should start local
> threads/services first before calling super.serviceStart(). Certain services
> have this reversed as below - leading to possibilities where the service
> would be in state STARTED, but in reality might not have started yet.
> {code}
> void serviceStart() {
> super.serviceStart()
> // service sepecific logic and start operations
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
