[
https://issues.apache.org/jira/browse/YARN-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968808#comment-13968808
]
Karthik Kambatla commented on YARN-1929:
----------------------------------------
bq. Now, there is one little quirk by desynchronizing the serviceStart() and
serviceStop methods. Although it is still impossible to have >1 thread
successfully entering either method, there is the sequence
AbstractService.stateChangeLock appears to allow a single thread to make any
state change at a given point in time. In the example, Thread 2's stop would
wait for Thread1's start() to complete. No?
> DeadLock in RM when automatic failover is enabled.
> --------------------------------------------------
>
> Key: YARN-1929
> URL: https://issues.apache.org/jira/browse/YARN-1929
> Project: Hadoop YARN
> Issue Type: Bug
> Components: resourcemanager
> Environment: Yarn HA cluster
> Reporter: Rohith
> Assignee: Karthik Kambatla
> Priority: Blocker
> Attachments: yarn-1929-1.patch, yarn-1929-2.patch
>
>
> Dead lock detected in RM when automatic failover is enabled.
> {noformat}
> Found one Java-level deadlock:
> =============================
> "Thread-2":
> waiting to lock monitor 0x00007fb514303cf0 (object 0x00000000ef153fd0, a
> org.apache.hadoop.ha.ActiveStandbyElector),
> which is held by "main-EventThread"
> "main-EventThread":
> waiting to lock monitor 0x00007fb514750a48 (object 0x00000000ef154020, a
> org.apache.hadoop.yarn.server.resourcemanager.EmbeddedElectorService),
> which is held by "Thread-2"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)