java.io.IOException is raised when tests use a large class path

[rsassi]

Describe the bug All the OS has limits when starting new processes:

• Linux e.g. ARG_MAX (https://www.in-ulm.de/~mascheck/various/argmax/)
• Windows (https://docs.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/command-line-string-limitation#:~:text=The%20maximum%20length%20of%20the,the%20command%20line)

The proposal: generate a class path jar with manifest to work around the limitation

Expected behavior The test must be always executed

Actual behavior When the tests use a large class path an java.io.IOException is thrown (see stack trace below) org.quickperf.issue.JvmError: java.io.IOException: Cannot run program "C:\Tools\Java\AdoptOpenJDK\Hotspot\JDK_8u272_b10_X64\jre\bin\java": CreateProcess error=206, The filename or extension is too long

Caused by: java.io.IOException: Cannot run program "C:\Tools\Java\AdoptOpenJDK\Hotspot\JDK_8u272_b10_X64\jre\bin\java": CreateProcess error=206, The filename or extension is too long at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) at org.quickperf.testlauncher.NewJvmTestLauncher.execute(NewJvmTestLauncher.java:112) at org.quickperf.testlauncher.NewJvmTestLauncher.executeTestInNewJvm(NewJvmTestLauncher.java:73) at org.quickperf.testlauncher.NewJvmTestLauncher.executeTestMethodInNewJwm(NewJvmTestLauncher.java:43) at org.quickperf.junit4.MainJvmAfterJUnitStatement.evaluateBusinessOrTechnicalIssue(MainJvmAfterJUnitStatement.java:77) at org.quickperf.junit4.MainJvmAfterJUnitStatement.evaluate(MainJvmAfterJUnitStatement.java:59) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.quickperf.spring.junit4.QuickPerfSpringRunner.runChild(QuickPerfSpringRunner.java:214) at org.quickperf.spring.junit4.QuickPerfSpringRunner.runChild(QuickPerfSpringRunner.java:37) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.quickperf.spring.junit4.QuickPerfSpringRunner.run(QuickPerfSpringRunner.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:66) Caused by: java.io.IOException: CreateProcess error=206, The filename or extension is too long at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.(ProcessImpl.java:444) at java.lang.ProcessImpl.start(ProcessImpl.java:139) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) ... 26 more

To Reproduce Define a pom.xml with huge of dependencies and try to run any simple test that use the class org.quickperf.testlauncher.NewJvmTestLauncher

Versions

• QuickPerf: 1.1.0
• JDK: AdoptOpenJDK, Hotspot, JDK_8u272_b10_X64
• OS: Windows
• Database (if SQL annotation bug): not used

Additional context (Add any other context about the problem here.) The implementation is done in my repository clone (checking the contribution guidelines before creating the PR)

[jeanbisutti]

Many thanks @rsassi for having reported this bug and proposing a fix.

This bug concerns the JVM annotations.

I had a first look at the fix. It seems great!

What do you think about creating a PR to fix this bug?

An automated test reproducing the problem would have been great, but it would not have been easy to create. Maybe you know of an open-source project where it would be possible to apply a JVM annotation of QuickPerf and reproduce the problem.

[rsassi]

Hi @jeanbisutti,

I fixed the issues using JFR 8.1.0 instead of using JFR 7.1.0 + write the required tests + create a branch with the recommended contribution guide lines

FYI: I have some issue when Spring try to inject beans, the investigation is inprogress to check the root cause. I will try to back ASAP with the PR

[jeanbisutti]

Hi @rsassi,

JFR 8.1.0 is another topic, not related to this bug. This topic needs to be discussed. JFR 8.1.0 requires at least Java 8 and may impact the behavior of ExpectNoJvmIssue annotation. This issue is rather huge.

Please, at first, create a request specifically dedicated to this bug. Thanks!

[rsassi]

Hi @jeanbisutti,

What I mean in my preview comment, JFR 7.1 has an license issue (I can use it only on my personnel laptop => in my free time). The second problem, I don't found a public repository to get the dependencies. can you help me?

For the JFR 8.1.0, I used it to fixe the issue as workaround and I must create a feature request to upgrade the version (require an approve of quick-perf committers). That must resolve the license issue (upgrade Java 8 is the constraint)

Conclusion:

• The present branch in my repo issue/174: is create to help quick-perf user to fixe the problem
• A new branch will be created for the PR with JFR 7.1.0
• Others tickets will be created to solve upgrade JFR + (new) fixe inherent some new information's from parent process to his child (like properties, ...)

[jeanbisutti]

Hi @rsassi,

I don't see a license problem. I explain why below.

We have to consider two things about the licenses:

• The analysis of the profiling files, the . jfr files. It is done by QuickPerf with the help of org.openjdk.jmc dependencies. The license of these dependencies is Universal Permissive License, so they can be included into an Apache License 2.0 project (see this page), the licence used by QuickPerf. When you write JFR 7.1 or JFR 8.1.0, it's about org.openjdk.jmc dependencies at version 7.1 or version 8.1.0. 8.x dependencies are published on Maven Central. 7.x dependencies avaiblable on the JFrog repositoty. You can look at this (QuickPerf pom). Do you have an issue with the JFrog repository? I downloaded JMC dependencies from JFrog with a Maven command a few days ago.
• The Flight Recording, the profiling mechanism embedded into the JVM. It was open-sourced from JDK 11. The feature was backported on OpenJDK JDK 8 with a version greater than u262/u272 (following vendors). Having said that, what about an Oracle JVM with version 1.7u40<=version<11? As you can see on this page, "Java Mission Control requires a commercial license for use in production. ". In this sentence, "Java Mission Control" includes the profiling mechanism embedded into the JVM and a graphical tool to analyze the profiling results. QuickPerf is a testing library, so it is not something used in production, and so I don't see a licence problem in this case.

[jeanbisutti]

Hi @rsassi,

Do you still have an issue with the JFrog repository? Can I help you?

[jeanbisutti]

Hi @rsassi,

I have just added on master a Maven profile to be able to disable the jfr-annotations module (containing the org.openjdk.jmc dependency): mvn clean install -P -jfr. Could you please create a first PR with just the code fixing the bug? I will merge it into master. Thank you.

[jeanbisutti]

Hi @rsassi,

I created a PR based on your fix. I added you as an author and as a QuickPerf contributor.

Many thanks for your help!

You are very welcome if you would like to contribute more.

Jean