Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISPN-7141 LimitedExecutorTest.testConcurrencyLimit random failures #4633

Closed

Conversation

danberindei
Copy link
Member

assertFalse(cf2.isDone());

latch.countDown();
assertEquals("bla", cf1.get(10, SECONDS));
assertEquals("bla", cf2.get(10, SECONDS));
eventuallyEquals(0, executor::getActiveCount);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you still need the two threads with this eventuallyEquals? I would rather move that on the beginning of the test method, as this line may not be reached upon test failure (and you don't want to fail the next test method).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I realized I actually needed 2 threads for testConcurrencyLimit().
But I added another eventuallyEquals() call at the beginning of the test methods that use the executor.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so the 2 threads are there to allow the possibility that the tasks will run in parallel, right? But what do you actually test here? The test confirms that eventually both tasks will be executed, but there's nothing testing the level of parallelism.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added javadocs to the test methods. testConcurrencyLimit() uses regular execute(), so it needs 2 threads to check that one task really blocks the other. This test method doesn't need 2 threads, because it uses executeAsync(), and the 1st task blocks the executor without using any threads.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would still add a check into the second task verifying that the first task has finished; otherwise you could replace LimitedExecutor with some executor that starts executing the second task a bit later (than the 10 ms) and it would still succeed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess having written LimitedExecutor myself, I didn't think it could ever delay a task without a good reason :)
Anyway, I've updated the test to better deal with the possibility.

@danberindei danberindei force-pushed the ISPN-7141_LimitedExecutorTest branch 5 times, most recently from 1db88dd to 066e711 Compare November 8, 2016 08:08
@danberindei danberindei force-pushed the ISPN-7141_LimitedExecutorTest branch 2 times, most recently from 802fc51 to 2bc98b0 Compare November 8, 2016 18:20
@rvansa
Copy link
Member

rvansa commented Nov 9, 2016

The tests would work with single blocker as well, but I think this is good to be integrated as-is.

* Increase the thread pool size to 2 for testConcurrencyLimit
* Wait for the executor to settle before/after each test
@wburns
Copy link
Member

wburns commented Nov 11, 2016

Pulling..

@wburns
Copy link
Member

wburns commented Nov 11, 2016

Integrated into master, thanks @danberindei !

@wburns wburns closed this Nov 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants