[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312857#comment-17312857
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 4/1/21, 4:42 AM:
------------------------------------------------------------------------
{quote}To be more specific in {{ForkStarter}}, the statement
{{CommandlineStreams streams = exec.execute()}} happens before
{{forkChannel.connectToClient()}}. The method should return our custom object
similar to {{Future}}, where we would have a method {{complete()}} implementing
{{verifySessionId()}} from {{SurefireForkChannel}}.{quote}
This is a good idea, but unfortunately it is not that simple. I tried according
to your description, and the build hangs anyway. I do agree that some ordering
problem is involved, though.
We need to say goodbye to the notion that the JVM logging something is
unexpected or not a real test situation. The JVM can log many things, depending
on command line parameters. It can be class-loading, debugging info about SSL
handshakes or whatever. Of course, Java agents can also print something to
standard out/err, but that is merely a special case. It is just a situation we
have to deal with. If the asynchronous fork node stuff is meant to work in
Surefire, it needs to be expected and handled accordingly.
Thinking aloud: If I understood [~tibordigana] correctly before, Surefire and
the forked VM communicate with each other via standard in/out. A good
alternative might be a dedicated socket for communication, not standard
in/out/err. Those channels should just be left untouched and only logged in the
Surefire parent process. But of course with some kind of filtering, JVM logging
information could also be separated from Surefire client-server communication
using some magic bytes around Surefire messages. It would just be more messy
and harder to test for regressions.
*Update:* Another reason not to communicate via standard in/out is that some
tests might use something ugly like {{System.setOut(..)}} in order to verify
side effects such as a called method, component or server (think integration
test) logging something.
was (Author: kriegaex):
{quote}To be more specific in {{ForkStarter}}, the statement
{{CommandlineStreams streams = exec.execute()}} happens before
{{forkChannel.connectToClient()}}. The method should return our custom object
similar to {{Future}}, where we would have a method {{complete()}} implementing
{{verifySessionId()}} from {{SurefireForkChannel}}.{quote}
This is a good idea, but unfortunately it is not that simple. I tried according
to your description, and the build hangs anyway. I do agree that some ordering
problem is involved, though.
We need to say goodbye to the notion that the JVM logging something is
unexpected or not a real test situation. The JVM can log many things, depending
on command line parameters. It can be class-loading, debugging info about SSL
handshakes or whatever. Of course, Java agents can also print something to
standard out/err, but that is merely a special case. It is just a situation we
have to deal with. If the asynchronous fork node stuff is meant to work in
Surefire, it needs to be expected and handled accordingly.
Thinking aloud: If I understood [~tibordigana] correctly before, Surefire and
the forked VM communicate with each other via standard in/out. A good
alternative might be a dedicated socket for communication, not standard
in/out/err. Those channels should just be left untouched and only logged in the
Surefire parent process. But of course with some kind of filtering, JVM logging
information could also be separated from Surefire client-server communication
using some magic bytes around Surefire messages. It would just be more messy
and harder to test for regressions.
> 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)
