Activity

There's a race in the test. MockRM.finishAMAndVerifyAppState only waits until the app is in a completed state, but the delegation token renewer can still be processing an asynchronous event associated with that completion. If the test tries to look at the renewer state before that event has been completely processed then tests can fail.

Here's a patch that changes each instance of MockRM.finishAMAndVerifyAppState in the test with a method that will do that and also wait for the specified token to stop being referenced by the application that is completing.

Jason Lowe
added a comment - 20/Jul/16 15:15 There's a race in the test. MockRM.finishAMAndVerifyAppState only waits until the app is in a completed state, but the delegation token renewer can still be processing an asynchronous event associated with that completion. If the test tries to look at the renewer state before that event has been completely processed then tests can fail.
Here's a patch that changes each instance of MockRM.finishAMAndVerifyAppState in the test with a method that will do that and also wait for the specified token to stop being referenced by the application that is completing.

Thanks for the patch Jason Lowe, encountered the same stack trace in YARN-4855 too. And seems like approach taken in the patch makes sense to me we wait for 10 seconds in a loop which is checking in a interval of 10 ms and throws the exception, though later in the test case we try to assert the same.
So overall LGTM and +1 , if not further comments will commit it.

Naganarasimha G R
added a comment - 03/Oct/16 07:19 Thanks for the patch Jason Lowe , encountered the same stack trace in YARN-4855 too. And seems like approach taken in the patch makes sense to me we wait for 10 seconds in a loop which is checking in a interval of 10 ms and throws the exception, though later in the test case we try to assert the same.
So overall LGTM and +1 , if not further comments will commit it.