Thanks for reporting this. Could you share the YARN configurations, please ? Bibin A Chundatt

Xuan Gong Sorry for late reponse.
-Also make sure that in capacity scheduler xml configuration should fail with nodeLabel

Updated description since the cases can happen in many cases . Please do correct me if i am wrong

Sorry typo. Both RM active can happen in many cases.

Thank you Bibin A Chundatt. Could you please attach CS xml too.

Thnks Sunil G for checking the issue. In this jira we should decide how to handle RefreshAll() failure during transistion to active. The configuration mistakes like capacityscheduler.xml , Acl , user group mapping can cause both RM active case during switch due to zk connection error probably.

At runtime i am not sure again we will be able to recover once this happens.

Capacity scheduler causing this case is one of them.
YARN-3894 contains the CS xml.

How about add rm.transitionToStandby(true) before we throw the ServiceFailedException in catch block ?

    try {
      rm.transitionToActive();
      // call all refresh*s for active RM to get the updated configurations.
      refreshAll();
      RMAuditLogger.logSuccess(user.getShortUserName(),
          "transitionToActive", "RMHAProtocolService");
    } catch (Exception e) {
      RMAuditLogger.logFailure(user.getShortUserName(), "transitionToActive",
          "", "RMHAProtocolService",
          "Exception transitioning to active");
      throw new ServiceFailedException(
          "Error when transitioning to Active mode", e);
    }

In that case, we could transit the RM to standby, and since we throw out the ServiceFailedException, this RM will rejoin the leader election process.

Hi Xuan Gong
Thank you for the update. I have a doubt here.

If we call rm.transitionToStandby(true) , then it will result a call to ResourceManager#createAndInitActiveServices().
So is it possible that we may get the same exception which we got from refreshAll call earlier. Specifically queue reinitialize. Currently the CS#serviceInit will call parseQueues. As mentioned here, Bibin A Chundatt used a wrong CS xml file.

Maybe set the HA service state in RM context as STANDBY upon throwing the exception. Or not set it to ACTIVE till the all active services are actually started.
We primarily check RM context to make the decision about whether RM is in standby state or active.

refreshAll() is doing many set of refresh operations. And exception may come from any state. Its better to gracefully close those. So setting state directly wont help much, we may need to go through part of transitionToStandby.

Sunil G
We can do the cleanup(i.e. stop active services) when we switch to standby. We do this already. Also cleanup will be done when we stop RM. So this shouldn't be an issue.

What is happening is as under :

Let us assume there is RM1 and RM2.
Basically, when exception occurs, RM1 waits for RM2 to become active and joins leader election again. As both RMs' have wrong configuration, RM1 will try to become active again(and not switch to standby) after RM2 has tried the same.
Now, as the problem is in call to refreshAll, both RMs' would be marked as ACTIVE in their respective RM Contexts. Because we set it to ACTIVE before calling refreshAll.

The problem reported here is that RM is shown as Active when it is not actually ACTIVE i.e. UI is accessible and getServiceState returns both RM as Active. And when we access UI or get service state we check what's the state in RM Context. And that is ACTIVE.
So for anyone who is accessing RM from command line or via UI, RM is active(because RM context says so), when it is not really active. Both RMs' are just trying incessantly to become active and failing.

That is why I suggested that we can update the RM Context. Infact changing RM context is necessary. We can decide when to stop active services, if at all.

So there are 2 options :

1. We can set RM context to standby when exception occurs and stop active services. But if we do it, this would mean we will have to redo the work of starting active services again if this RM were to become ACTIVE.
2. Introduce a new state (say WAITING_FOR_ACTIVE) and set this state when exception is thrown and check this state to stop active services when switching to standby. And not starting the services again in case of switching to ACTIVE.

Thoughts, Sunil G, Xuan Gong ?

For 2nd option, we will have to return STANDBY to client if the state is WAITING_FOR_ACTIVE. So it can primarily be a RM internal state.

Thanks Varun Saxena for sharing detailed analysis. Infact we must change the state in context.

IMO, I feel we can stop active services, and move the RM state to Standby. With this, RM will become another candidate for election. If any case when the same RM is selected as active, and if we have good config, then with existing call flow startActiveServices will be invoked. So it should be fine in that case. From UI also, both RM will be shown as Standby too.

Yeah lets go with first option I suggested then i.e. make RM Context as standby and stop active services followed by initialization. That will be easier to implement.
This will resolve the issue.

Thanks Varun Saxena and Sunil G first option look good and easier to implement.
But both RM could be in standBy state. but looks like the best option.

Varun Saxena and Sunil G . Only need to call rm.transitionToStandby(false) on exception .
Since it handles transition to standby in rm context,Stop active services and not reinitializing queues.

Reinitialization of Active Services is required. When you call stop active services, service state for all the services will change to STOPPED.
If this RM were to become active again, we will try to start all the active services and services cant transition to START state from STOPPED state. They can only do so when services are in INIT state.

Hi Varun Saxena

Reinitialization of Active Services is required.

For this, I think calling rm.transitionToStandby(true) is not a good idea. Because same exception can come while initializing CapacityScheduler (cs config file).

Hi Varun Saxena

Reinitialization of Active Services is required.

For this, I think calling rm.transitionToStandby(true) is not a good idea. Because same exception can come while initializing CapacityScheduler (cs config file).

How about first calling rm.transitionToStandby(false), then call activeService.reinitiate() (probably need to create this function) ? At least, the RM will transit to Standby. Even if the reinitiate() throws exception, the leader elector will handle this.

Sorry, should call stopAndReinitiate().

Hi Xuan Gong
Yes, we can do that. But I feel now we call rmContext.setHAServiceState(HAServiceProtocol.HAServiceState.STANDBY);
as last statement in transitionToStandby. SO if an exception happens in reinitialize code flow wont reach to set the state as Standby. So we may also need to set the state in context as Standby.

Yes but we do need to reinitialize services. Otherwise transition to active when everything is fine will not happen.

We do need to stop active services because many threads would be spawned on attempt to transition to active.
Frankly, we can have a additional flag in RM indicating that reinitialization of services is required and attempt them while trying for transition to active. We can stop the services beforehand because no point having some threads running in standby. Thoughts ?
We can do something like below

      // Exception was thrown in call to refreshAll.
      if (rmContext.getHAServiceState() ==
          HAServiceProtocol.HAServiceState.ACTIVE) {
      ((RMContextImpl)rmContext).setHAServiceState(HAServiceProtocol.HAServiceState.STANDBY);
        try {
          rm.stopActiveServices();
          // set a flag in RM(maybe rm context) indicating reinit of services is required on trying for transition to active despite state being standby.
        } catch (Exception ex) {        
        }

I remember an earlier suggestion of new HAServiceState.
Introducing a state as WAITING_FOR_ACTIVE may help to do all reinit or other inits when we try to move to ACTIVE. Also as mentioned earlier, this can be hidden state internally. It may look more cleaner than flag. So along with above solution, could we add this new state also?

Xuan Gong, issue with reinitialization is that if exception is thrown during initialization then all the active services will be stopped.
And when we transitiontoactive we will directly attempt to start active services which would fail because services are in state STOPPED.

I think we can forcibly set the state to standby and set a flag in RMContext indicating reinit is required whenever attempting transition to standby or active. This way we will let leader election handle the exception.

Yeah Sunil G, a new state can also be introduced as I suggested. This would act similar to a flag.

Xuan Gong, thoughts about introducing a new internal state ?

We have to be very careful though when we do this as this is a very sensitive piece of code.

Thanks for Varun Saxena and Sunil G. I am fine with adding a new internal state although it might be too complex. But if we could handle this correctly, I am fine with this.

To this specific issue, I think that at least two things we should do here:
1) stop All ActiveService
2) transit to standby. (basically, set RM state in RMContext as Standby)
But, we also need to reinitiate all the active service to prepare for the transitToActive call.
At least, we should do:

rm.transitToStandy(false);
reinitiateActiveService();

Here the reinitiateActiveService() can throw out the same exception. And I can see why this does not solve the whole problem.

How about we introduce a new atomicBoolean flag to track whether we need to reinitiate active service ? And we could add following into transitToActive logic

    if (reinitiateRequired)
       reinitiateActiveService()

before we start all the active service.

Ok, lets add a flag. According to me, we need to check this flag and do reinit even on transitionToStandby even though state is standby.

+1 for using atomicBoolean flag.
Do we really need to call reinitiateActiveService from transitionToStandby. I think it can be done while we invoke transitionToActive when it matters.

Sunil G, even I was suggesting earlier in my comment that we reinit only while transitioning to active.

But then I thought that if we reinit on standby and there is a problem in initialization, a failure can indicate the admin to correct his config. An audit log will be printed.
If we do not reinit, a success audit log on transition to standby would be printed, which may indicate no problem in config to admin.
Thoughts ?

We can procrastinate reiniting till transition to active as well. But its better to indicate a failure even on standby IMHO. I do not see any harm in it.
I am fine either ways because reiniting really matters when transitioning to active.

I am fine either ways though because as you said reiniting really matters when transitioning to active.

Sunil G, Varun Saxena and Xuan Gong Thanks a lot for comments.
Please review

-1 overall

This message was automatically generated.

-1 overall

This message was automatically generated.

Thanks for the patch Bibin A Chundatt. Few comments.

1. Nit : Should be "Exception in state transition"

             throw new ServiceFailedException(
                 "Exception in state transistion", re);
   

2. IMO, no need to throw ServiceFailedException when catching exception while calling reinitialize. The throw below should suffice. Just set the flag. According to me, we should retain the original exception.
3. Add a comment indicating what the flag does.
4. Maybe rename the flag to reinitActiveServices instead of reinitialize.
5. The flag according to me, semantically speaking, doesn't quite belong to AdminService. Can be in ResourceManager or RMContext. Thoughts ?
6. Can you add a test to verify the fix ?
7. I think instead of relying on transitionToStandby to change state to standby, we can explicitly change the state in AdminService. Thats because even stopActiveServices can throw an Exception and if it does, state won't change to STANDBY. This call to stop should not throw an exception, but as services keep on getting added you never know how a particular service may behave. We should be immune to it. Try something like below.

    ((RMContextImpl)rmContext).setHAServiceState(HAServiceProtocol.HAServiceState.STANDBY);
   

8. Just a suggestion. If we do above, maybe call stopActiveServices and reinitialize directly instead of calling transitonToStandby. This is because as I said in a comment above, transitionToStandby would print an audit log saying transition is successful. But reinitialize subsequently may fail. And not printing this audit log will be consistent with transitionToActive failing during starting active services. Thoughts ?

Attaching patch after comment update and adding testcase

+1 overall

This message was automatically generated.

Bibin A Chundatt

1. Instead of checking for exception message in test, can you check for ServiceFailedException ?
2. Can you add a verification in the test to check whether active services were stopped ?

Instead of checking for exception message in test, can you check for ServiceFailedException

Already the same is verified in may testcases using messages.

Can you add a verification in the test to check whether active services were stopped ?

IMO its not required.

Sorry for coming very late.. This issue has become stale, need to move forward!!
Regarding the patch,

1. Instead of setting boolean flag for reinitActiveServices in AdminService and other changes, moving createAndInitActiveServices(); from transitionedToStandby to just before starting activeServices would solve such issues. And on exception transitioningToActive, handle add method stopActiveServices in ResourceManager#transitioningToActive() only.
2. Probably we can remove refreshAll() from AdminService#transitioneToActive if the above approach.

Any thoughts?

Hi Rohith Sharma K S
Thank you for your review comments
Will update the same and upload patch soon.

Hi Rohith Sharma K S
Thank you for restarting this thread.

The idea of calling createAndInitActiveServices from both ResourceManager#transitionToActive() and transistionToStandby is good . In this case, we can remove the call to refreshAll from AdminService#transistionToStandby.

Hi Rohith Sharma K S
On a second thought, could we move refreshAll in AdminService#transitionToStandby/Active ahead of rm.transitionToStandby/Active

    try {
      // call all refresh*s for active RM to get the updated configurations.
      refreshAll();
      rm.transitionToActive();
      RMAuditLogger.logSuccess(user.getShortUserName(),
          "transitionToActive", "RMHAProtocolService");
    } catch (Exception e) {
      RMAuditLogger.logFailure(user.getShortUserName(), "transitionToActive",
          "", "RMHAProtocolService",
          "Exception transitioning to active");
      throw new ServiceFailedException(
          "Error when transitioning to Active mode", e);
    }

Hence exception can come before invoking transition methods in ResourceManager class. Thoughts?

Hi Rohith Sharma K S
Any comments on this.?

I had closer look at either of the solutions as above. One of the potential issue in both are

1. Moving createAndInitService just before starting activeServices in transitionToActive.
   1. switch time will be impacted since every transitionToActive initializes active services.
   2. And RMWebApp has dependency on clienRMService for starting webapps. Without clientRMService initialization, RMWebapp can not be started.
2. Moving refreshAll before transitionToActive in adminService is same as triggering RMAdminCIi on standby node. This call throw StandByException and retried to active RM in RMAdminCli. When it comes to AdminService#transitionedToActive(), refreshing before rm.transitionedToActive throws an standby exception.

I think for any configuration issues while transitioningToActive, Adminservice should not allow JVM to continue. Because if AdminService throws any exception back to elector, elector again try to make RM active which goes in loop forever filling the logs.
There could be 2 calls can lead to point of failures i.e first rm.transitionedToActive, second refreshAll().

1. If any failures in rm.transitionedToActive then RM services will be stopped and RM will be in STANDBY state.
2. If refreshAll() fails, BOTH RM will be in ACTIVE state as per this defect. Continuing RM services with invalid configuration does not good idea. Moreover invalid configurations should be notified to user immediately. So it would be better to make use of fail-fast configuration to exit the RM JVM. If this configuration is set to false , then call rm.handleTransitionToStandBy.

Using fail fast makes sense.

Hi Rohith Sharma K S and Sunil G

Thanks for comments.

1. So createAndInitActiveServices approach will not take

Second approach sounds good with fail fast.
I have updated the patch as per the suggestion. Please review

Thanks Bibin A Chundatt for updating the patch. The patch mostly reasonable!!
Some comments on the patch

1. Does {{isRMActive() }} check is required..? If transitionedToActive is success only then refreshAll will be executed!! IAC if you add also then check should be common for both i.e _if_else
2. In the Test, below code expecting transitionToActive to be failed? Is so, then it RM state shoud not be in Active state. Why RM will be in Active if adminService fails to transition?

   +    try {
   +      rm.adminService.transitionToActive(requestInfo);
   +    } catch (Exception e) {
   +      assertTrue("Error when transitioning to Active mode".contains(e
   +          .getMessage()));
   +    }
   +    assertEquals(HAServiceState.ACTIVE, rm.getRMContext().getHAServiceState());
   

3. Have you verified the test locally? I have doubt that test may be exitted in the middle since you are changing the scheduler configuration. Scheduler configuration is loaded during transitionedToStandby which fails to load and System.exit is called.

To be more clear on the 3rd point, handleTransitionToStandBy call will exit if transitionToStandby fails. This transition may fail because during transition, active services are initialized. CS initialization loads the new capacity-schduler conf which result in wrong default queue capacity value result standby transition failure.
4. Instead of having separate class FatalEventCountDispatcher , can it be made inline?

Few additional comments :

• Below exception block i.e. exception block after call to refreshAll, if YarnConfiguration.shouldRMFailFast(getConfig()) is true, we merely post fatal event and do not return or throw an exception. This would lead to success audit log for transition to active being printed, which doesn't quite look correct. Because we are encountering some problem during call to transition. We should either return or throw a ServiceFailedException here as well. Although both are OK because RM would anyways be down later but I would prefer exception.

   
  324	    } catch (Exception e) {
  325	      if (isRMActive() && YarnConfiguration.shouldRMFailFast(getConfig())) {
  326	        rmContext.getDispatcher().getEventHandler()
  327	            .handle(new RMFatalEvent(RMFatalEventType.ACTIVE_REFRESH_FAIL, e));
  328	      }else{
  329	        rm.handleTransitionToStandBy();
  330	        throw new ServiceFailedException(
  331	            "Error on refreshAll during transistion to Active", e);
  332	      }
  333	    }
  334	    RMAuditLogger.logSuccess(user.getShortUserName(), "transitionToActive",
  335	        "RMHAProtocolService");
  336	  }
  

• In TestRMHA, below import is unused.

  	import io.netty.channel.MessageSizeEstimator.Handle;
  

• A nit : There should be a space before else.

  328	      }else{
  329	        rm.handleTransitionToStandBy();
  

• In the test added, assert is not required in the exception block after first call to transitionToActive

• Maybe we can add an assert in test for service state being STANDBY after call to transitionToActive with incorrect capacity scheduler config and fail-fast being false.

Moreover, the fail fast configuration doesnt quite work as expected here. If capacity scheduler configuration is wrong, initialization will again fail and JVM will exit, which in essence is exactly same as the other case. We can handle fail fast as true case same way as earlier IMO.

The reason it works in the test(JVM does not exit) is that you have passed CapacitySchedulerConfiguration object to MockRM. As CapacitySchedulerConfiguration is not instanceof YarnConfiguration, this will lead to a new YarnConfiguration object being created and passed to ResourceManager.
When you are changing configuration in test and set queue capacity to 200, it is not reflecting in the Configuration object in ResourceManager class. That is why JVM does not exit when we transition to standby.

Sorry I meant we can handle fail fast config being false case same way as we were doing in earlier patches. Otherwise checking for fail fast doesnt make any difference because both the code paths lead to same result.

There are 2 type of refresh can happen i.e. 1. yarn-site.xml refresh, 2. scheduler configurations refresh. Schduler configurations are reloaded for every service initialization which is by design. If any issue in the scheduler configuration, fail-fast configuraton behavior work as same for both true and false. Fail-fast configuration is useful when admin do mistake in configuring mistake in yarn-site.xml. With wrong configuration in yarn-site.xml, RM service can be up whereas with wrong Scheduler configuration , service can NOT be up at all. On best effort basis for make service up, handling exception for yarn-site.xml and scheduler configuration are different.

BTW, making RM state StandBy would lead to filling up of the logs very soon because of elector continuous try to make active. Any configuration issue, better to exit the JVM and notify admin that RM is down so that admin can check the logs and identify it.

Hmm...my point of view based on the fact that the service cannot be up if atleast one RM is not active. Standby RM is not going to serve anything anyways.
Till configurations of this RM are not corrected, whether yarn-site or scheduler configurations, this RM anyways cant become active (refreshAll will always fail). And you can say there might be some silly mistake in scheduler configuration too.

What we were doing before in the patch wont fill up the logs if configuration is ok on other RM. And if its not Ok on other RM, logs will fill up even even if refreshAll fails because of something other than scheduler config(and fail fast is false).
fail fast by default is true, and if admin is making it false, he will know what to expect.

But, you can say a RM shutting down is a far more alarming thing for an admin and scheduler configurations more important. I agree with that. Maybe we can make RM with wrong configuration down at all times. Because till he correct the config(whether yarn-site or scheduler config), this RM cant become active.

Let us take opinion of couple of others as well on this. We can do whatever is the consensus.

In previous patches, we were delaying reinitialization till attempting transition to active again and not attempting it immediately as we have done here. Any issues you expect with that ?

Saw your comments above. We cant do what we were doing earlier because as you say WebApp should be up even in standby. Let me think if something else can be done.

Hi Varun Saxena, trying to understand your point of statement, my suggestion is to exit the RM if any configuration issue during refreshAll during AdminService#transitionToActive. As I given reason for making RM JVM down rather than keeping JVM alive in earlier comment, do you have any concern for exiting the RM for configuration issues?

I do not have any concern for exiting JVM. If fail fast is true(default behavior), JVM will exit anyways.

I was wondering if it would be semantically appropriate to make JVM exit in some cases if somebody has explicitly changed the fail fast config to false. Logs can fill up if yarn-site.xml is wrong on both RMs' too.

I am not sure about the webapp part though. Does it require client rm service to be initialized ? AFAIK, if RM is standby it will hit the webapp filter and redirect to other RM(which may be active). Haven't tested UI after applying previous patches, so maybe Bibin can tell. If there are some issues with webapp, we will have to exit the JVM if transition to standby fails. Because there may be no other way out then.
I will discuss further on this with you offline.

Infact according to me, we can crash RM on all times if config is wrong. Because till config is corrected, the RM where config is wrong cannot become active(and hence will be unusable). In that case, fail fast config wont even be required. So should we change the behavior to keep RM in standby(but up) if fail fast is set to false ? Anyways can discuss more in detail face to face.

As I see this, JVM exit is reasonable as proposed by Rohith earlier. Because scheduler configurations are wrong mostly, and its not required to switch to standby or fail-fast etc. Directly if we can exit JVM, it will be clean and there will be enough information available in logs to analyze for config fail reasons.

Yes I agree. We can exit JVM directly. No need of using fail fast.

So JVM exit is the conclusion after discussion.
Attaching patch based on the same

Missed one comment isRMActive check is not required.Attaching patch again

The latest patch, 0008-YARN-3893.patch LGTM.
+1 pending Jenkins.

-1 overall

This message was automatically generated.

-1 overall

This message was automatically generated.

+1 overall

This message was automatically generated.

Test failures are not related to this patch. Have looked into the failed testcases

hadoop.yarn.server.resourcemanager.security.TestClientToAMTokens - Due Bind exception
hadoop.yarn.server.resourcemanager.scheduler.fair.TestAllocationFileLoaderService - Locally verified its working fine and success
hadoop.yarn.server.resourcemanager.TestClientRMService -Ran locally in eclipse its working fine

Above comments are for https://builds.apache.org/job/PreCommit-YARN-Build/8915/testReport/

Hi Bibin A Chundatt,
Thanks for the patch, test cases ran fine, approach and test case seems to be fine but few comments from my side

1. timeout of 900000 is on the higher side is that much req or was it for local testing ?
2. instead of test case in RMHA can we think of adding it to TestRMAdminService as the failure is related to transition to Active ?
3. May be while throwing RMFatalEvent better to wrap it with another exception wrapping the existing one and with the message that transition to active failed so that RM Logs have clear information on what operation it exited. or may be eventType instead of having ACTIVE_REFRESH_FAIL we can have more intuitive name TRANSITION_TO_ACTIVE_FAILED

Hi Naga

Thnks for looking into patch

timeout of 900000 is on the higher side is that much req or was it for local testing ?

will update the same.

instead of test case in RMHA can we think of adding it to TestRMAdminService as the failure is related to transition to Active ?

As i understand all transistiontoActive & HA related testcases are added in same class.

3.TRANSITION_TO_ACTIVE_FAILED is not actually failing its refreshAll rt? Thts the reason it gave specific name.

Points 2 and 3 are not mandatory fix items rt?

Attaching patch after handling comments.

1. timeout updated in testcase
2. Changed from ACTIVE_REFRESH_FAIL to TRANSITION_TO_ACTIVE_FAILED

Hi Bibin A Chundatt
2> there are test cases related to transition in TestRMAdminService.testRMHAWithFileSystemBasedConfiguration but most of it is present in TestRMHA so i think it should be fine.

3> Well IMHO it would be better be handled in the later approach i suggested, as refreshAll is just a private method but actual operation is transistionToActive which Failed which is more readable than ACTIVE_REFRESH_FAIL

Oops saw this message late !

Oops saw this message late !

-1 overall

This message was automatically generated.

Testcase failures are not related to this patch.

+1 lgtm.. Will commit it tomorrow if there is no objections/comments from other folks..

committed to branch-2.7.2, branch-2 and trunk.. thanks Bibin!!

+1...lgtm too

FAILURE: Integrated in Hadoop-trunk-Commit #8387 (See https://builds.apache.org/job/Hadoop-trunk-Commit/8387/)
YARN-3893. Both RM in active state when Admin#transitionToActive failure from refeshAll() (Bibin A Chundatt via rohithsharmaks) (rohithsharmaks: rev 7d6687fe76f6152a577ff2298c358dd30fce41fb)

• hadoop-yarn-project/CHANGES.txt
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestRMHA.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/RMFatalEventType.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/AdminService.java

FAILURE: Integrated in Hadoop-Yarn-trunk #1070 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/1070/)
YARN-3893. Both RM in active state when Admin#transitionToActive failure from refeshAll() (Bibin A Chundatt via rohithsharmaks) (rohithsharmaks: rev 7d6687fe76f6152a577ff2298c358dd30fce41fb)

• hadoop-yarn-project/CHANGES.txt
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestRMHA.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/AdminService.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/RMFatalEventType.java

SUCCESS: Integrated in Hadoop-Yarn-trunk-Java8 #342 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/342/)
YARN-3893. Both RM in active state when Admin#transitionToActive failure from refeshAll() (Bibin A Chundatt via rohithsharmaks) (rohithsharmaks: rev 7d6687fe76f6152a577ff2298c358dd30fce41fb)

• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/AdminService.java
• hadoop-yarn-project/CHANGES.txt
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/RMFatalEventType.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestRMHA.java

SUCCESS: Integrated in Hadoop-Mapreduce-trunk-Java8 #335 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/335/)
YARN-3893. Both RM in active state when Admin#transitionToActive failure from refeshAll() (Bibin A Chundatt via rohithsharmaks) (rohithsharmaks: rev 7d6687fe76f6152a577ff2298c358dd30fce41fb)

• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/AdminService.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestRMHA.java
• hadoop-yarn-project/CHANGES.txt
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/RMFatalEventType.java

FAILURE: Integrated in Hadoop-Hdfs-trunk #2264 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2264/)
YARN-3893. Both RM in active state when Admin#transitionToActive failure from refeshAll() (Bibin A Chundatt via rohithsharmaks) (rohithsharmaks: rev 7d6687fe76f6152a577ff2298c358dd30fce41fb)

• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/RMFatalEventType.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/AdminService.java
• hadoop-yarn-project/CHANGES.txt
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestRMHA.java

FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #325 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/325/)
YARN-3893. Both RM in active state when Admin#transitionToActive failure from refeshAll() (Bibin A Chundatt via rohithsharmaks) (rohithsharmaks: rev 7d6687fe76f6152a577ff2298c358dd30fce41fb)

• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestRMHA.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/AdminService.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/RMFatalEventType.java
• hadoop-yarn-project/CHANGES.txt

SUCCESS: Integrated in Hadoop-Mapreduce-trunk #2284 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2284/)
YARN-3893. Both RM in active state when Admin#transitionToActive failure from refeshAll() (Bibin A Chundatt via rohithsharmaks) (rohithsharmaks: rev 7d6687fe76f6152a577ff2298c358dd30fce41fb)

• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/RMFatalEventType.java
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/AdminService.java
• hadoop-yarn-project/CHANGES.txt
• hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestRMHA.java

Hi Bibin A Chundatt, Rohith Sharma K S and Xuan Gong, is this bug also valid on branch-2.6? If so, may be we should consider to backport to branch-2.6?

I think it should be there in 2.6 too, let me cross confirm it. If exist, I will backport this to 2.6

This issue is valid for branch-2.6. I have back ported to 2.6.4

Thanks Rohith Sharma K S!

FAILURE: Integrated in Hadoop-trunk-Commit #9060 (See https://builds.apache.org/job/Hadoop-trunk-Commit/9060/)
Add YARN-2975, YARN-3893, YARN-2902 and YARN-4354 to Release 2.6.4 entry (junping_du: rev b6c9d3fab9c76b03abd664858f64a4ebf3c2bb20)

• hadoop-yarn-project/CHANGES.txt