[
https://issues.apache.org/jira/browse/FLINK-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976447#comment-15976447
]
ASF GitHub Bot commented on FLINK-6130:
---------------------------------------
Github user tillrohrmann commented on the issue:
https://github.com/apache/flink/pull/3726
@zhangminglei please refrain from pulling more and more people into the
loop by directly referencing them given that this is a trivial change and that
5 people are already involved.
Looking at the `YarnFlinkApplicationMasterRunner` I think it could benefit
from some more refactoring. For example, I don't think that we need to have an
`AbstractYarnFlinkApplicationMasterRunner` base class. Both can be combined in
one class. Then we can instantiate the services and runtime components in the
constructor of `YarnFlinkApplicationMasterRunner`. That way we can get rid of
the lock in the `run` method.
Given that, I'm not sure whether this PR makes then sense anymore. I think
we can close it.
> Consider calling resourceManager#getTerminationFuture() with lock held
> ----------------------------------------------------------------------
>
> Key: FLINK-6130
> URL: https://issues.apache.org/jira/browse/FLINK-6130
> Project: Flink
> Issue Type: Bug
> Reporter: Ted Yu
> Assignee: mingleizhang
> Priority: Minor
>
> In YarnFlinkApplicationMasterRunner#runApplicationMaster() :
> {code}
> synchronized (lock) {
> LOG.info("Starting High Availability Services");
> ...
> }
> // wait for resource manager to finish
> resourceManager.getTerminationFuture().get();
> {code}
> resourceManager#getTerminationFuture() is called without holding lock.
> We should store the value returned from
> resourceManager#getTerminationFuture() inside the synchronized block.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
