[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312260#comment-17312260
]
Tibor Digana commented on SUREFIRE-1881:
----------------------------------------
[~kriegaex]
My answer to your pre-previous questions. ;-)
> Is there some communication going on using the forked VM's output channels
> stdOut and/or stdErr?
yes, i will explain the interprocess communication from the point of forked JVM:
1. socket connects to 127.0.0.1:port and observes a reference to the TCP client
2. Surefire creates an instance ForwardingPrintStream in ConsoleOutputCapture
3. ConsoleOutputCapture calls System.setOut() and redirects the std/out to the
TCP client writter
4. if any native stream, after (3), contains messages then it means that JVM
printed them and they are considered a GC messages or native error and we
propagate them. (4) should not exist in healthy build.
We do not have any communication because we are at (1). Both plugin JVM and
surefire JVM are in the position where waiting for a connection. This was seen
in the jconsole.exe when connected to plugin JVM and it was seen in the
[stacktrace|https://issues.apache.org/jira/browse/SUREFIRE-1881?focusedCommentId=17311716&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17311716].
I may debug both to make sure that we have right observations in the evening.
The logs and dump files you can see are handled from the pipe stream of the
process.
The reason why Surefire has this process 1 - 3 is the fact that we have to
associate a test with its logs (can be running in parallel). Then we are able
to isolate the XML reports per test and class. Next reason is that the events
are sent from JVM to plugin. Commands are sent from plugin and received by the
surefire JVM.
> Does the parent VM read from the respective streams and maybe expect some
> special messages in a specific order, which might not arrive as expected
> because there is regular JVM or Java agent log output in between those
> messages?
Not, for sure because both parts attempt to connect and the connection has not
moved forward. Therefore the data could not be transfered. No handshaking has
pased yet.
I am not trying to forget this issue, absolutely not, but the symptoms must
make sense in regard of code whatever it means Surefire or JDK.
I can check {{forkChannel}} in the class {{ForkStarter}} if it is closed or not.
Several years ago we also had curious error and my colleagues expected a bug in
Surefire. Don't be wondering, we developed a small prototype, and copied the
code from Surefire to a tiny JAR file which worked on Unix. After two weeks of
very intensive discussions we found that the system was out of disk space.
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> ------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
> Affects Versions: 3.0.0-M5
> Reporter: Alexander Kriegisch
> Assignee: Tibor Digana
> Priority: Major
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{<forkNode
> implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
