Re: [BEAM-4088] Test isolation differences in Gradle

+1, thks Etienne for the hard work and to have spent time on it even if gradle was making it more complicated, really appreciated. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

Re: [BEAM-4088] Test isolation differences in Gradle

Hi guys, After some investigations, it appears to be a timing problem in the test. If we bloc until the end of the threads in metricsExecutorService before the ThreadLeakTracker rule is exectuted, then the test passes in gradle (no leaks detected). I guess we were lucky with the other build runs

Re: [BEAM-4088] Test isolation differences in Gradle

What I am trying to figure out is which of these we have: (a) the "test is broken" scenario - pass in maven (thread did not leak) - pass in idea (thread did not leak) - fail in gradle (thread did not leak, but the test incorrectly thinks one did) (b) the "found a bug" scenario - pass in

Re: [BEAM-4088] Test isolation differences in Gradle

@Kenn,  Yes it is through the Elasticsearch test framework that you reference that I discovered that direct runner counter metrics thread leaked. I opened this ticket  https://issues.apache.org/jira/browse/BEAM-3119 at the time. But it seemed overkill to ship ES test framework in Romain's PR unit

Re: [BEAM-4088] Test isolation differences in Gradle

No, otherwise it wouldnt pass in idea and maven. Le 19 avr. 2018 00:57, "Kenneth Knowles" a écrit : Does the test think a thread leaked when no thread leaked? On Wed, Apr 18, 2018 at 1:51 PM Romain Manni-Bucau wrote: > The leaking threadq are already

Re: [BEAM-4088] Test isolation differences in Gradle

Does the test think a thread leaked when no thread leaked? On Wed, Apr 18, 2018 at 1:51 PM Romain Manni-Bucau wrote: > The leaking threadq are already dumped but we dont track who created it > > Le 18 avr. 2018 22:50, "Kenneth Knowles" a écrit : > >> For

Re: [BEAM-4088] Test isolation differences in Gradle

The leaking threadq are already dumped but we dont track who created it Le 18 avr. 2018 22:50, "Kenneth Knowles" a écrit : > For this particular test, is it failing because a different test class > leaked threads? Is there a way to make something like a testing base class >

Re: [BEAM-4088] Test isolation differences in Gradle

For this particular test, is it failing because a different test class leaked threads? Is there a way to make something like a testing base class with @Before and @After actions that would catch the leak closer to where it happened? A quick search found this:

Re: [BEAM-4088] Test isolation differences in Gradle

Le 18 avr. 2018 18:53, "Scott Wegner" a écrit : I wanted to provide some additional information about this issue and Gradle test configuration. For context, BEAM-4088 [1] refers to a new test on PR/4965 [2] which verifies that no threads are being leaked. Under Maven the

[BEAM-4088] Test isolation differences in Gradle

I wanted to provide some additional information about this issue and Gradle test configuration. For context, BEAM-4088 [1] refers to a new test on PR/4965 [2] which verifies that no threads are being leaked. Under Maven the test passes, but under Gradle it reports leaked threads [3]. I'm not