Repository navigation
YARN-12004. Fix Router-vs-RM read races in TestRouterWebServicesREST. - #8787
Conversation
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
@slfan1989 Hi, as you reviewed also YARN-11984, would you mind having a look at this router PR as well? |
testAppXML, testAppStateXML, testAppAttemptXML and testGetContainersXML compared one Router read with one RM read of a value the RM was still changing. assertRouterMatchesRM reads the RM, then Router, then the RM again, and retries until the RM is stable around the Router read and Router matches it. testGetContainersXML compares container IDs rather than counts. A single-address performGetCall replaces the duplicated request code and closes every client it creates. Contains content generated by Claude Code. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
I cut the PR in two parts, so it is easier to review independently. The other fix is in YARN-12006. |
|
🎊 +1 overall
This message was automatically generated. |
@joseluisll Thanks for reaching out! I’m happy to review this Router PR and will take a look. |
slfan1989
left a comment
There was a problem hiding this comment.
Thanks for the fix. Reading the RM before and after the Router response appropriately handles the lifecycle races, and comparing container IDs improves the validation.
I verified that the helper retries when the RM changes and still fails when the Router consistently disagrees with a stable RM. CI is green.
LGTM, +1.
|
@joseluisll Thanks for the contribution! Merged into trunk. |
Required by (waits for this one to be merged):
Description of PR
JIRA: https://issues.apache.org/jira/browse/YARN-12004
Supersedes #8786.
TestRouterWebServicesREST, andTestFederationWebAppwhich extends it, fail intermittently on CI becausetestAppXML,testAppStateXML,testAppAttemptXMLandtestGetContainersXMLeach compared one Router read with one RM read of a value the RM was still changing (AM host, state, attempts, containers), e.g.expected: <ACCEPTED> but was: <SUBMITTED>. The change is test-only, inTestRouterWebServicesREST.java.assertRouterMatchesRM(path, type, key)reads the RM, then the Router, then the RM again, compares a key extracted from each answer, and retries (up to 10s) until the RM was stable around the Router read and the Router matches it.testGetContainersXMLcompares container IDs rather than counts, so one AM container replacing another is seen as a change.performGetCallreplaces the duplicated Router/RM request code, and every client it creates is closed.How was this patch tested?
Locally on Linux with OpenJDK 21 and Maven 3.9.11, in
hadoop-yarn-server-router, on this PR's head:mvn test -Dtest=TestRouterWebServicesREST,TestFederationWebApp: 94 tests (42 + 52), 0 failures, 0 errors.For code changes:
declared according to the connector-specific documentation? Note: Automated CI
testing doesn't cover all cases so manual testing with cloud storage is still
required. N/A, no object storage changes.
LICENSE,LICENSE-binary,NOTICE-binaryfiles? N/AAI Tooling
If an AI tool was used:
where is the name of the AI tool used.
https://www.apache.org/legal/generative-tooling.html
Contains content generated by Claude Code.