[
https://issues.apache.org/jira/browse/SUREFIRE-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated SUREFIRE-1931:
------------------------------------------
Description:
While re-testing the fix for SUREFIRE-1881, [~tibordigana] and I agreed to add
some integration tests in order to ensure correct behaviour. Everything is
fine, the tests pass since Tibor fixed the problem. But the same tests would
time out before the bugfix commits or in case of a regression due to an
undetected edge case or a refactoring, accidentally re-introducing the problem.
I also tested that the timeouts work as expected, simply back-porting the ITs
to a branch before the bugfix.
Now here is the problem: While the timeouts fire correctly, the running test
JVMs are not terminated and continue running as zombie processes.
* See [this PR|https://github.com/apache/maven-surefire/pull/355] for related
discussion and details about how to detect the zombie processes
* See [this
branch|https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881]
with the back-ported fixes, if you need a simple way to recreate the error
situation.
The PR also describes how to reproduce the problem:
{quote}If you want to easily reproduce the hanging JVMs directly in Surefire
ITs, I ported both SUREFIRE-1881 tests from this PR back to the state before
the merge. Simply check out my branch
{{[before-SUREFIRE-1881|https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881]}},
make a clean build without tests and then run the ITs. The easiest way is to
temporarily add {{<test>Surefire1881IT</test>}} to the Failsafe config in the
IT module. Of course you can also add the corresponding Maven CLI option.
{quote}
Because SUREFIRE-1881 is fixed and this is a more general problem with regard
to the Surefire test infrastructure as such, Tibor asked me to open a separate
issue. I agree that this is the best approach, but please do read the
information gathered in the closed PR. There, I also mentioned that MSHARED-867
might be related to this issue, but I am not sure. It just sounds similar and I
found it during my research.
was:
While re-testing the fix for SUREFIRE-1881, [~tibordigana] and I agreed to add
some integration tests in order to ensure correct behaviour. Everything is
fine, the tests pass since Tibor fixed the problem. But the same tests would
time out before the bugfix commits or in case of a regression due to an
undetected edge case or a refactoring, accidentally re-introducing the problem.
I also tested that the timeouts work as expected, simply back-porting the ITs
to a branch before the bugfix.
Now here is the problem: While the timeouts fire correctly, the running test
JVMs are not terminated and continue running as zombie processes.
* See [this PR|https://github.com/apache/maven-surefire/pull/355] for related
discussion and details about how to detect the zombie processes
* See [this
branch|https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881]
with the back-ported fixes, if you need a simple way to recreate the error
situation.
The PR also describes how to reproduce the problem:
{quote}If you want to easily reproduce the hanging JVMs directly in Surefire
ITs, I ported both SUREFIRE-1881 tests from this PR back to the state before
the merge. Simply check out my branch
{{[before-SUREFIRE-1881|https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881]}},
make a clean build without tests and then run the ITs. The easiest way is to
temporarily add `<test>Surefire1881IT</test>` to the Failsafe config in the IT
module. Of course you can also add the corresponding Maven CLI option.
{quote}
Because SUREFIRE-1881 is fixed and this is a more general problem with regard
to the Surefire test infrastructure as such, Tibor asked me to open a separate
issue. I agree that this is the best approach, but please do read the
information gathered in the closed PR. There, I also mentioned that MSHARED-867
might be related to this issue, but I am not sure. It just sounds similar and I
found it during my research.
> Integration test timeout causes zombie Java processes
> -----------------------------------------------------
>
> Key: SUREFIRE-1931
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1931
> Project: Maven Surefire
> Issue Type: Bug
> Affects Versions: 3.0.0-M5
> Reporter: Alexander Kriegisch
> Priority: Major
>
> While re-testing the fix for SUREFIRE-1881, [~tibordigana] and I agreed to
> add some integration tests in order to ensure correct behaviour. Everything
> is fine, the tests pass since Tibor fixed the problem. But the same tests
> would time out before the bugfix commits or in case of a regression due to an
> undetected edge case or a refactoring, accidentally re-introducing the
> problem. I also tested that the timeouts work as expected, simply
> back-porting the ITs to a branch before the bugfix.
> Now here is the problem: While the timeouts fire correctly, the running test
> JVMs are not terminated and continue running as zombie processes.
> * See [this PR|https://github.com/apache/maven-surefire/pull/355] for
> related discussion and details about how to detect the zombie processes
> * See [this
> branch|https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881]
> with the back-ported fixes, if you need a simple way to recreate the error
> situation.
> The PR also describes how to reproduce the problem:
> {quote}If you want to easily reproduce the hanging JVMs directly in Surefire
> ITs, I ported both SUREFIRE-1881 tests from this PR back to the state before
> the merge. Simply check out my branch
> {{[before-SUREFIRE-1881|https://github.com/kriegaex/maven-surefire/tree/before-SUREFIRE-1881]}},
> make a clean build without tests and then run the ITs. The easiest way is to
> temporarily add {{<test>Surefire1881IT</test>}} to the Failsafe config in the
> IT module. Of course you can also add the corresponding Maven CLI option.
> {quote}
> Because SUREFIRE-1881 is fixed and this is a more general problem with regard
> to the Surefire test infrastructure as such, Tibor asked me to open a
> separate issue. I agree that this is the best approach, but please do read
> the information gathered in the closed PR. There, I also mentioned that
> MSHARED-867 might be related to this issue, but I am not sure. It just sounds
> similar and I found it during my research.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
