[GitHub] [zookeeper] kezhuw opened a new pull request, #1821: ZOOKEEPER-4327: Fix flaky RequestThrottlerTest.testLargeRequestThrottling
kezhuw opened a new pull request, #1821: URL: https://github.com/apache/zookeeper/pull/1821 This test failed following assertions in ci: 1. `RequestThrottlerTest.testRequestThrottler:206 expected: <5> but was: <4>` This is caused by no happens-before relationship between `connectionLossCount` and `disconnected.await`. Places `disconnected.countDown()` after `connectionLossCount++` to solve this. 2. `RequestThrottlerTest.testLargeRequestThrottling:297 expected: <2> but was: <0>` Large request throttling is handled in io thread, while `prep_processor_request_queued` metric is updated in processor thread. Places metric assertion after `finished.await` to solve this. Additionally, I find one more potential flaky case. After connection closed due to throttling third request, reconnecting could fail this test in slow sending environment. It is easy to reproduce by adding `Thread.sleep(i * 100)` in sending loop. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@zookeeper.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [zookeeper] kezhuw opened a new pull request #1821: ZOOKEEPER-4327: Fix flaky RequestThrottlerTest.testLargeRequestThrottling
kezhuw opened a new pull request #1821: URL: https://github.com/apache/zookeeper/pull/1821 This test failed following assertions in ci: 1. `RequestThrottlerTest.testRequestThrottler:206 expected: <5> but was: <4>` This is caused by no happens-before relationship between `connectionLossCount` and `disconnected.await`. Places `disconnected.countDown()` after `connectionLossCount++` to solve this. 2. `RequestThrottlerTest.testLargeRequestThrottling:297 expected: <2> but was: <0>` Large request throttling is handled in io thread, while `prep_processor_request_queued` metric is updated in processor thread. Places metric assertion after `finished.await` to solve this. Additionally, I find one more potential flaky case. After connection closed due to throttling third request, reconnecting could fail this test in slow sending environment. It is easy to reproduce by adding `Thread.sleep(i * 100)` in sending loop. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@zookeeper.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org