You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by GitBox <gi...@apache.org> on 2021/07/04 06:21:33 UTC
[GitHub] [maven-surefire] kriegaex opened a new pull request #355: [SUREFIRE-1881] - Fix and extend integration test
kriegaex opened a new pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355
This PR is a follow-up on #354.
Done already:
- Renamed `Surefire1881` to `Surefire1881IT`, because with the wrong name the test was not even executed before according to the CI build logs
- Now in addition to the Java agent logging IT executed in Failsafe, there also is a JVM logging IT executed in Surefire. Both tests were in different branches of https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems.
**TODO:** I cherry-picked the tests back on the commit before the merge of SUREFIRE-1881 in order to verify that when a JVM hang occurs, the tests actually time out and kill the forked JVMs. The timeouts do actually occur, both for both test cases (JVM logging, Java agent) the JVMs hang:
In the screenshot above, you see two process groups still running indefinitely until killed manually, long after the test timeouts occurred and the build is finished. Per hanging test, you even see two JVMs, one for Maven and one forked by Surefire/Failsafe. All in all, per hanging test we even have 4 processes (2 JVMs, one shell and one console host) on Windows. Probably on Linux is it similar.
This means that simple JUnit test timeouts are not good enough to clean up processes in case of hanging tests, which could always occur, either here due to regressions or uncovered edge cases or in other ITs due to other types of errors. Both on developer workstations and on CI servers like Jira, this can quickly deplete resources.
@Tibor17 and everyone else, do you have any ideas how to clean up the zombie processes correctly?
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874450203
> Closing as not willing to read tons of text.
Great reason, thank you so much. Other OSS maintainers complain about under-specified issues. Your complaint is a luxury complaint. If you have so little time, read more thoroughly, answer more precisely and be happy about saving tons of time due to fewer misunderstandings.
> I do not have time to read kilobytes of text for simple issues.
Tibor, I am sorry to remind you that all this text would have been unnecessary if you would have read the shorter text in the original issue description correctly. Everything that followed was based on you misunderstanding it due to sloppy reading and first claiming the issue to be irrelevant, before promising to fix it. "You reap what you sow", they say. You are part of the problem, I was not talking to myself here but trying to explain things to you.
> Improvements will be fixed as I promised.
Thank you, looking forward to it. I promise that despite your dysfunctional and condescending behaviour here, I am still willing to help you re-test this, if you need support. Just notify me in new issues or PRs.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873987237
What are you talking about? I didn't **want** to write so much, if it wasn't so super hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool.
We should care about this problem because none other than Maven creates the zombie processes, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak?
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
So because I used a GUI tool from SysInternals disqualifies me as a developer? It proves what? That you are a real developer and I am not? Can you be any more condescending?
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch what Maven does live. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` command only shows a subset of the same information, because the fact is missing that it is not just Java processes but a group of 4 processes per test case. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from SysInternals `procexp64` when running Maven from Git Bash:
**Update:** When running from cmd.exe, there are only two processes left per test timed out method, not 4:
The difference between both shells seems to originate from the fact that Git Bash forks a cmd.exe when running Maven, so there is more stuff to clean up. Why Maven in one case (cmd.exe) can terminate the parent Java process and just not the child, but in the other case (Git Bash) cannot terminate either of them, is to be investigated.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874015200
zombie process may happen if and only if two things happen:
1. enabled TCP impl is broken (default PING mechanism does not inform surefire subprocess that Maven has stopped)
2. Maven build was interrupter/stopped in surefire/failsafe plugin.
It is not so critical at the moment but it may happen. I will open Jira ticket and i will think about the old config param.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
So because I used a GUI tool from SysInternals disqualifies me as a developer? It proves what? That you are a real developer and I am not? Can you be any more condescending?
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch what Maven does live. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` command only shows a subset of the same information, because the fact is missing that it is not just Java processes but a group of 4 processes per test case. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from procexp64:
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873764177
Please note my update at the end of https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758 concerning differences in leftover zombie processes between cmd.exe and Git Bash.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873987237
What are you talking about? I didn't **want** to write so much, if it wasn't so shower hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a real problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool.
We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak?
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873987237
What are you talking about? I didn't **want** to write so much, if it wasn't so super hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool.
We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak?
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874045506
Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before, you
* falsely claimed multiple times that this PR did not contain your previous bugfix,
* called the back-ported reproducer test case in the other branch "irrelevant",
* did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just acknowledged it now in your most recent 2 comments - thanks for that),
* for no good reason copied my commits instead of merging this PR.
Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine.
> `<forkedProcessTimeoutInSeconds>15</forkedProcessTimeoutInSeconds>`
Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad.
BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you. Of course, I can adjust my PR to be like yours, i.e. a single project with both Surefire and Failsafe settings all in one. If you had told me to do it like that in a normal code review, I would have done so.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873987237
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873712057
> Here is the [history ](https://github.com/kriegaex/maven-surefire/commits/before-SUREFIRE-1881)of commits in your repo - no fix!
You don't get it, do you? This PR (branch `SUREFIRE-1881-fix` ) does contain the fixes! Branch `before-SUREFIRE-1881` is just for reproducing what would happen in case of a regression, because I needed a way to emulate that situation. What is so difficult to understand about it? This is why I named the other branch accordingly, with an explicit `before-` prefix in the branch name, and described it as a backport.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873987237
What are you talking about? I don't wanted to write so much, but obviously didn't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a real problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool.
We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak?
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873976776
@kriegaex
It is not understandable that you are able to spend our time on these thing. You can write some document in DZone on "How to find zombie process in java" but we are not interested in this elaborate document!
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873764177
Please note my update at the end of https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758 concerning differences in leftover zombie processes between cmd.exe and Git Bash. I also mentioned a Windows CLI tool to display a process tree.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
So the fact that I used a GUI tool from SysInternals disqualifies me as a developer? It proves what? That you are a real developer and I am not? Can you be any more condescending?
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch what Maven does, live while it was happening. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` command only shows a subset of the same information, because the fact is missing that it is not just Java processes but a group of 4 processes per test case. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it, and you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from SysInternals `procexp64` when running Maven from Git Bash:
**Update:** When running from cmd.exe, there are only two processes left per test timed out method, not 4:
The difference between both shells seems to originate from the fact that Git Bash forks a cmd.exe when running Maven, so there is more stuff to clean up. Why Maven in one case (cmd.exe) can terminate the parent Java process and just not the child, but in the other case (Git Bash) cannot terminate either of them, is to be investigated.
**Update 2:** If you prefer CLI tools, install MS SysInternals Suite, make sure it is on the path and use tool `pslist64` like this (lots of other processes cut out from the console log):
```none
$ pslist64 -t
Name Pid Pri Thd Hnd VM WS Priv
...
java 1176 8 34 459 10212488 165004 290360
cmd 2820 8 1 83 2151734644 5152 2568
java 4564 8 7 132 10082892 14304 337220
conhost 18576 8 2 103 2151778712 10680 5480
java 7964 8 34 478 10234976 236356 292148
cmd 13888 8 1 83 2151734644 5152 2568
conhost 7224 8 2 103 2151778712 10700 5472
java 11104 8 22 269 10133584 34848 340900
...
```
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, I did run the test from Maven(!), simply used a GUI tool to watch what Maven does live. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` shows the same information, only with less detail, because the fact that it is not just Java processes but a group of 4 processes per test case is missing. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from procexp64:
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
So the fact that I used a GUI tool from SysInternals disqualifies me as a developer? It proves what? That you are a real developer and I am not? Can you be any more condescending?
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch what Maven does, live while it was happening. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` command only shows a subset of the same information, because the fact is missing that it is not just Java processes but a group of 4 processes per test case. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from SysInternals `procexp64` when running Maven from Git Bash:
**Update:** When running from cmd.exe, there are only two processes left per test timed out method, not 4:
The difference between both shells seems to originate from the fact that Git Bash forks a cmd.exe when running Maven, so there is more stuff to clean up. Why Maven in one case (cmd.exe) can terminate the parent Java process and just not the child, but in the other case (Git Bash) cannot terminate either of them, is to be investigated.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
So the fact that I used a GUI tool from SysInternals disqualifies me as a developer? It proves what? That you are a real developer and I am not? Can you be any more condescending?
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch what Maven does, live while it was happening. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` command only shows a subset of the same information, because the fact is missing that it is not just Java processes but a group of 4 processes per test case. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it, and you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from SysInternals `procexp64` when running Maven from Git Bash:
**Update:** When running from cmd.exe, there are only two processes left per test timed out method, not 4:
The difference between both shells seems to originate from the fact that Git Bash forks a cmd.exe when running Maven, so there is more stuff to clean up. Why Maven in one case (cmd.exe) can terminate the parent Java process and just not the child, but in the other case (Git Bash) cannot terminate either of them, is to be investigated.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873560441
According to the CI results, now `Surefire1881IT` is actually (and successfully for both cases) executed. So far, so good. Why in one case on MacOS `JUnit47ParallelIT.forcedShutdownVerifyingLogs` failed, I do not know, but I think I have seen it before. It looks like this test is flaky and should be fixed (in another PR).
When looking at https://github.com/kriegaex/maven-surefire/actions, you see what happens in the back-ported tests, e.g. [here](https://github.com/kriegaex/maven-surefire/actions/runs/997851433). Of course, in the log there is no way to find out about the hanging processes which are never terminated, but for that you can look at my screenshot above or just run the test locally, keeping count of Java processes with a process manager.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 closed pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 closed pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873712057
> Here is the [history ](https://github.com/kriegaex/maven-surefire/commits/before-SUREFIRE-1881)of commits in your repo - no fix!
You don't get it, do you? This PR (branch `SUREFIRE-1881-fix` ) does contain the fixes! Branch `before-SUREFIRE-1881` is just for reproducing what would happen in case of a regression, because I needed a way to emulate that situation. What is so difficult to understand about it? This is why I named the other branch accordingly, with an explicit `before-` prefix in the branch name, and described it as a **backport**:
> 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.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873766789
I just found https://issues.apache.org/jira/browse/MSHARED-867 and left a comment. It could be related to the problem described here.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874045506
Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before you
* falsely claimed multiple times that this PR did not contain your previous bugfix,
* called the back-ported reproducer test case in the other branch "irrelevant",
* did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just just acknowledged it now in your most recent 2 comments - thanks for that),
* for no good reason copied my commits instead of merging this PR.
Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine.
> `<forkedProcessTimeoutInSeconds>15</forkedProcessTimeoutInSeconds>`
Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad.
BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you. Of course, I can adjust my PR to be like yours, i.e. a single project with both Surefire and Failsafe settings all in one. If you had told me to do it like that in a normal code review, I would have done so.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874045506
Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before you
* falsely claimed multiple times that this PR did not contain your previous bugfix,
* called the back-ported reproducer test case in the other branch "irrelevant",
* did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just just acknowledged it now in your most recent 2 comments - thanks for that),
* for no good reason copied my commits instead of merging this PR.
Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine.
> <forkedProcessTimeoutInSeconds>15</forkedProcessTimeoutInSeconds>
Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad.
BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874450203
> Closing as not willing to read tons of text.
Great reason, thank you so much.
> I do not have time to read kilobytes of text for simple issues.
Tibor, I am sorry to remind you that all this text would have been unnecessary if you would have read the shorter text in the original issue description correctly. Everything that followed was based on you misunderstanding it due to sloppy reading and first claiming the issue to be irrelevant, before promising to fix it. "You reap what you sow", they say. You are part of the problem, I was not talking to myself here but trying to explain things to you.
> Improvements will be fixed as I promised.
Thank you, looking forward to it. I promise that despite your dysfunctional and condescending behaviour here, I am still willing to help you re-test this, if you need support. Just notify me in new issues or PRs.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874015200
zombie process may happen if and only if two things happen:
1. enabled TCP impl is broken (default PING mechanism does not inform surefire subprocess that Maven has stopped)
2. Maven build was interrupter/stopped in surefire/failsafe plugin.
It is not so critical at the moment but it may happen. I will open Jira ticket and i will think about the old config param.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an endge case or
* accidentally the problem gets re-introduced in the future by someone elses change or refactoring.
This IT is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So testing what would happen if the test actually would run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, I did run the test from Maven(!), simply used a GUI tool to watch what Maven does live. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` shows the same information, only with less detail, because the fact that it is not just Java processes but a group of 4 processes per test case is missing. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from procexp64:
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874191056
@kriegaex
Closing as not willing to read tons of text. I do not have time to read kilobytes of text for simple issues. Improvements will be fixed as I promised.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 closed pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 closed pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874011834
@kriegaex
I have the source code in my mind and I know what should be done with the config parameter `<forkedProcessTimeoutInSeconds>15</forkedProcessTimeoutInSeconds>`. You can see this in my commit. Do you know how it works? You have to trust me that I know better than you and I take the responsibility for zombie processes. I am aware that they may happen in the TCP is broken again and that the user has to use `forkedProcessTimeoutInSeconds` but it cannot be solved like this in this PR. We have some way to inform the users about the features in surefire and their possible issues and we can propose treatments. I can see the risk in the ITs and we know what should be done, but the problem with this PR looks like a bug after HEAD commit in master - that's the problem, and many other contributors use to write straightforward and brief definition of issue. We need to have time to think about a solution to keep backward compatibility with `forkedProcessTimeoutInSeconds` and provide a solution b
ut the brain needs to have the time to think about it and this is normal. And normal is to post an issue in Jira to not to forget it.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874015200
zombie process may happen if and only if two things happen:
1. enabled TCP impl is broken (default PING mechanism does not inform surefire subprocess that Maven has stopped)
2. Maven build was interrupter/stopped in surefire/failsafe plugin.
It is not so critical at the moment but it may happen. I will open Jira ticket and i will think about the old config param.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873987237
What are you talking about? I didn't **want** to write so much, if it wasn't so super hard to convince you of anything. But obviously you don't understand that this is a real problem and didn't care to investigate by yourself or acknowledge the zombie processes as a real problem. Instead, you criticised that I used an admin tool with a GUI instead of a console tool.
We should care about this problem because none other than Maven creates them, they don't appear magically. When running the IT directly from its POM and pressing Ctrl-C, all child processes are terminated correctly. Only when running as part of the Surefire ITs, the zombie processes occur. How on earth can you **not** care and simply ignore an obvious, reproducible problem which is a huge system resource leak?
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
So the fact that I used a GUI tool from SysInternals disqualifies me as a developer? It proves what? That you are a real developer and I am not? Can you be any more condescending?
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch what Maven does live. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` command only shows a subset of the same information, because the fact is missing that it is not just Java processes but a group of 4 processes per test case. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from SysInternals `procexp64` when running Maven from Git Bash:
**Update:** When running from cmd.exe, there are only two processes left per test timed out method, not 4:
The difference between both shells seems to originate from the fact that Git Bash forks a cmd.exe when running Maven, so there is more stuff to clean up. Why Maven in one case (cmd.exe) can terminate the parent Java process and just not the child, but in the other case (Git Bash) cannot terminate either of them, is to be investigated.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-874045506
Of course you know better than me, which is why I sent my RFC about the open issue (zombie Java processes) in the first place. Now you finally have acknowledged that there actually **is** a problem. Before you
* falsely claimed multiple times that this PR did not contain your previous bugfix,
* called the back-ported reproducer test case in the other branch "irrelevant",
* did not explicitly acknowledge that the zombie processes are a problem you are going to fix (just acknowledged it now in your most recent 2 comments - thanks for that),
* for no good reason copied my commits instead of merging this PR.
Those things I was complaining and explaining about. Had you just acknowledged the problem before and somehow signalled that you are intending to fix them, either here or in a new issue/PR, it would have been fine.
> `<forkedProcessTimeoutInSeconds>15</forkedProcessTimeoutInSeconds>`
Well, that is nowhere to be found in your commits. Besides, I tried that before, both in the IT module settings and in the IT POMs themselves. I also tried the timeout in the IT tests themselves, all to no avail. If you see ways to improve this, I will be glad.
BTW, would you please be so kind as to revert your commit (or force-push the previous HEAD) and merge this PR instead? You created your commit under the false notion of my PR not being forked off of master. I really would like to see my own commits here as a small recognition of my contribution. I spent lots of time, trying to explain this PR to you. Of course, I can adjust my PR to be like yours, i.e. a single project with both Surefire and Failsafe settings all in one. If you had told me to do it like that in a normal code review, I would have done so.
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873976776
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an endge case or
* accidentally the problem gets re-introduced in the future by someone elses change or refactoring.
This IT is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So testing what would happen if the test actually would run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, I did run the test from Maven(!), simply used a GUI tool to watch what Maven does live. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` shows the same information, only with less detail, because the fact that it is not just Java processes but a group of 4 processes per test case is missing. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from procexp64:
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873688965
@kriegaex
You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
[I renamed the IT](https://github.com/apache/maven-surefire/commit/4a43a400eb52abaf5a833c814050c18ebc4ef421) in **master** and added the unit test as you did. Nobody is watching Windows task manager in order to send some proves because this is false representation. Instead, the developers use the command-line and precisely understand the console. Pls use this during and after the test in command-line. Do not use any IDE, use only console/cmd on your Windows system, as follows (includes real outcome during the test on [your test project](https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems)).
```
wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"c:\Program Files\Java\jdk1.8.0_281\bin\java.exe" -classpath "c:\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=c:\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=c:\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=c:\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\vcs\github\Maven_Surefire_PrintToConsoleProblems" org.codehaus.plexus.classworlds.launcher.Launcher -o verify
"c:\Program Files\Java\jdk1.8.0_281\jre\bin\java" -javaagent:C:\vcs\github\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar -jar C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439\surefirebooter1388721399876762247.jar C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439 2021-07-05T00-07-45_319-jvmRun1 surefire2890232333274079753tmp surefire_07190630157758286269tmp
```
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873987237
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873688965
@kriegaex
You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
[I renamed the IT](https://github.com/apache/maven-surefire/commit/4a43a400eb52abaf5a833c814050c18ebc4ef421) in **master** and [added the unit test](https://github.com/apache/maven-surefire/commit/aff6eebe59721ac3c318e277aaba711aca55aee6) similar you did here. Nobody is watching Windows task manager in order to send some proves because this is false representation. Instead, the developers use the command-line and precisely understand the console. Pls use this during and after the test in command-line. Do not use any IDE, use only console/cmd on your Windows system, as follows (includes real outcome during the test on [your test project](https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems)).
```
wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"c:\Program Files\Java\jdk1.8.0_281\bin\java.exe" -classpath "c:\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=c:\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=c:\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=c:\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\vcs\github\Maven_Surefire_PrintToConsoleProblems" org.codehaus.plexus.classworlds.launcher.Launcher -o verify
"c:\Program Files\Java\jdk1.8.0_281\jre\bin\java" -javaagent:C:\vcs\github\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar -jar C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439\surefirebooter1388721399876762247.jar C:\Users\tibor17\AppData\Local\Temp\surefire7956139842988037439 2021-07-05T00-07-45_319-jvmRun1 surefire2890232333274079753tmp surefire_07190630157758286269tmp
```
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone elses change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, I did run the test from Maven(!), simply used a GUI tool to watch what Maven does live. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` shows the same information, only with less detail, because the fact that it is not just Java processes but a group of 4 processes per test case is missing. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from procexp64:
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
Tibor17 commented on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873709894
@kriegaex
Here is the [history ](https://github.com/kriegaex/maven-surefire/commits/before-SUREFIRE-1881)of commits in your repo - no fix!
T
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-surefire] kriegaex edited a comment on pull request #355: [SUREFIRE-1881] - Fix and extend integration test
Posted by GitBox <gi...@apache.org>.
kriegaex edited a comment on pull request #355:
URL: https://github.com/apache/maven-surefire/pull/355#issuecomment-873703758
> You did not take my commit with the fix. Your HEAD commit in your repository contains your tests without the fix. So it is quite irrelevant.
What are you talking about?
You should read my PR correctly. The PR of course builds on top of your fixes, I branched it off of master. Please revert and merge my PR as prior art instead. I did this work, you were simply recreating it. These are my commits and I want them merged. If something is wrong with my PR, we can fix them, of course. The other branch without the fixes simply shows what would happen if
* we overlooked an edge case or
* accidentally the problem gets re-introduced in the future by someone else's change or refactoring.
This IT (like all tests) is meant to do two things:
* verify some assumptions about how the application should behave
* reproduce a problem, spotting regressions, in case it does not behave as expected
So, testing what would happen if the test actually _would_ run into a timeout due to a regression is very much relevant. I simply created the other branch for your convenience, so you can reproduce the problem with hanging JVMs not being cleaned up properly. That other branch is not a PR branch, this one is!
> Nobody is watching Windows task manager in order to send some proves because this is false representation.
Of course not, normally people just run the IT, relying on it behaving correctly. Cleaning up resources and fixtures is part of a test's correct behaviour, and I manually verified that for you. I noticed that resource clean-up is broken, which is why it should be fixed, because otherwise people **not** looking at a task manager or `htop` would never notice what is going on, until all the running processes from repeatedly running tests would cause out of memory errors on their workstations or CI servers.
> Instead, the developers use the command-line
So the fact that I used a GUI tool from SysInternals disqualifies me as a developer? It proves what? That you are a real developer and I am not? Can you be any more condescending?
Different developers use different tools. If the tool reveals the correct information, why does it matter if I started it from a console or from an IDE? Besides, **I did run the test from Maven(!),** simply used a GUI tool to watch what Maven does, live while it was happening. In that tool, I cannot just see the end result but also what happens during the test: First, each of the two Java process groups are indirect children of sh.exe (my Git Bash), which starts the Maven build. Then, each time one of the two tests is interrupted due to the timeouts, the subprocesses lose their parent (of course) and now move up the process hierarchy, hanging there as zombies without parents. Your `wmic` command only shows a subset of the same information, because the fact is missing that it is not just Java processes but a group of 4 processes per test case. My simple screenshot illustrates that way better.
You made a similar argument about my Process Explorer screenshot in the original Jira ticket, trying to fend off my information as irrelevant, claiming the Java agent to be the problem instead of Surefire. Like back then, you are also wrong in this case: The problem is real, my screenshot illustrates it, and you can easily reproduce it in my test branch. Of course, currently there is no known regression, but no software is perfect and regressions can always occur. To ensure that the ITs clean up their resources in case they fail due to a hanging JVM (which is exactly what they test should **not** happen), is part of the job of writing tests. So the job is not done yet.
But if it makes you happy, I replayed again on the console for you (ran inside the IT module after a previous full build with install):
```none
$ mvn -P run-its verify
(...)
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 60.054 s <<< FAILURE! - in org.apache.maven.surefire.its.jiras.Surefire1881IT
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJVMLogging(Surefire1881IT.java:37)
[ERROR] org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent Time elapsed: 30.011 s <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
at app//org.apache.maven.surefire.its.jiras.Surefire1881IT.testJavaAgent(Surefire1881IT.java:47)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] Surefire1881IT.testJVMLogging:37 » TestTimedOut test timed out after 30000 mil...
[ERROR] Surefire1881IT.testJavaAgent:47 » TestTimedOut test timed out after 30000 mill...
[INFO]
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
(...)
$ wmic PROCESS where "name like '%java%'" get Commandline
CommandLine
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJVMLogging" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,includ
es=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu test
"C:\Program Files\Java\jdk-16\bin\java" -verbose:class -jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653\surefirebooter4985087880621361102.jar C:\Users\alexa\AppData\Local\Temp\surefire2405688146490858653 2021-07-05T07-34-52_138-jvmRun1 surefire6407547456865244099tmp surefire_09695795624160661675tmp
"C:\Program Files\Java\jdk-16\bin\java.exe" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\apache-maven-3.6.3\bin\..\boot\plexus-classworlds-2.6.0.jar" "-Dclassworlds.conf=C:\Program Files\Java\apache-maven-3.6.3\bin\..\bin\m2.conf" "-Dmaven.home=C:\Program Files\Java\apache-maven-3.6.3\bin\.." "-Dlibrary.jansi.path=C:\Program Files\Java\apache-maven-3.6.3\bin\..\lib\jansi-native" "-Dmaven.multiModuleProjectDirectory=C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent" org.codehaus.plexus.classworlds.launcher.Launcher -e --batch-mode -Dmaven.repo.local=C:\Users\alexa\.m2\repository org.apache.maven.plugins:maven-clean-plugin:clean -Dsurefire.version=3.0.0-M6-SNAPSHOT -Djacoco.agent=-javaagent:C:\\Users\\alexa\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.7\\org.jacoco.agent-0.8.7-runtime.jar=destfile=C:\\Users\\alexa\\Documents\\java-src\\maven-surefire\\surefire-its\\target\\jacoco-it.exec,include
s=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/* -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -nsu verify
"C:\Program Files\Java\jdk-16\bin\java" -javaagent:C:\Users\alexa\Documents\java-src\maven-surefire\surefire-its\target\Surefire1881IT_testJavaAgent\target/surefire-1881-java-agent-1.0-SNAPSHOT.jar -jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543\surefirebooter12628764455616323129.jar C:\Users\alexa\AppData\Local\Temp\surefire1253544507142731543 2021-07-05T07-35-22_653-jvmRun1 surefire11527327993772670760tmp surefire_018188072805511397606tmp
```
The corresponding screenshot from SysInternals `procexp64` when running Maven from Git Bash:
**Update:** When running from cmd.exe, there are only two processes left per test timed out method, not 4:
The difference between both shells seems to originate from the fact that Git Bash forks a cmd.exe when running Maven, so there is more stuff to clean up. Why Maven in one case (cmd.exe) can terminate the parent Java process and just not the child, but in the other case (Git Bash) cannot terminate either of them, is to be investigated.
**Update 2:** If you prefer CLI tools, install MS SysInternals Suite, make sure it is on the path and use tool `pslist64` like this (lots of other processes cut out from the console log):
```none
$ mvn -DskipTests=true install
...
$ cd surefire-its
$ mvn -P run-its verify
...
$ pslist64 -t
Name Pid Pri Thd Hnd VM WS Priv
...
java 1176 8 34 459 10212488 165004 290360
cmd 2820 8 1 83 2151734644 5152 2568
java 4564 8 7 132 10082892 14304 337220
conhost 18576 8 2 103 2151778712 10680 5480
java 7964 8 34 478 10234976 236356 292148
cmd 13888 8 1 83 2151734644 5152 2568
conhost 7224 8 2 103 2151778712 10700 5472
java 11104 8 22 269 10133584 34848 340900
...
```
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org