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

Run tests in parallel #1032

merged 1 commit into from May 7, 2015


None yet
3 participants

arteam commented May 4, 2015

This is rebased and squashed version of #1012

I can't reproduce errors locally and on Travis. I've run the build a few dozens times and it passed.
I don't want to make the build flaky, but I have a feeling that's something were wrong with CI test environment.

If the build will nevertheless fail, this PR could remain opened, while we don't find the root cause.


This comment has been minimized.


arteam commented May 4, 2015

Ok, for some reason the build fails only when I run it as a pull-request to the project and it doesn't when I run it from my fork on Travis. Will investigate the stack trace...

UPD. Actually, I was able to reproduce the error in my fork.

Run tests in parallel
We added a workaround for a bug in sl4fj and removed
clashed tests in Dropwizard modules, so now it's should
be safe to run the tests in parallel.

It could highlight more bugs in tests, because the test
environment now will become more unstable and unpredicatable.
Which is probably not a bad thing, because more bugs will be
found in the development and testing, but in the production.

* Spin-loop the therad while the logger context is not initialized

Because of the bug a thread
that didn't start logging initialization has a possibilty to get
a reference not to a real logger context, but to a wrapper.

To workaround this we spin-loop the thread, while the context
is not initialized.

* Add MBean registration lock

We have a data race, if LoggerFactory is created in parallel.
Therefore we should guard the process of MBean registration

* Bootstrap the logging before testing

Doing so, we guarantee that the logger context is initialized
during tests.

* Remove not a relevant test

The test that checks that the final frame is the main method
is not relevant, because if it's called in the JUnit parallel
test runner, the last frame is from a custom thread. Because
of this the test fails.

* Use a random server port in Jersey tests

Otherwise these tests start testing HTTP servers on the
same port and they fail when the tests are run in parallel.

* Use random HTTPS port

Othwerise this test may confict with other test, that could
be run on the same port

* Support for a custom property prefix

It's crucial if we don't want situations, when independent
tests concurrently modify the same system property.

* Use different system property prefixes to avoid test clashing

Tests are now running in parallel, so we should use different
system properties for configuration overriding tests, otherwise
they will clash with each other make themselves not reliable.

This comment has been minimized.


arteam commented May 4, 2015

Figured out changing logging levels needs to be protected, because LoggerContext#loggerContextListenerList is not thread-safe.


This comment has been minimized.


carlo-rtr commented May 7, 2015


carlo-rtr added a commit that referenced this pull request May 7, 2015

@carlo-rtr carlo-rtr merged commit 7c37f4b into dropwizard:master May 7, 2015

@jplock jplock added this to the 0.9.0 milestone May 18, 2015

@arteam arteam referenced this pull request May 24, 2015


Migration tests #1070

@arteam arteam deleted the arteam:parallel_tests branch Jan 24, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment