[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312566#comment-17312566
]
Alexander Kriegisch commented on SUREFIRE-1881:
-----------------------------------------------
I experimentally made the test pass and the log output show by modifying
{{SurefireForkChannel::connectToClient}} as follows: I split
{{server.accept().get()}} into two calls and in between bound the event
handler. Schematically, it is like this - _*just for explanation,*_ I think you
get the idea, I am not showing all changes in method and interface signatures
involved:
{code:java}
Future<AsynchronousSocketChannel> channelFuture = server.accept();
bindEventHandler( eventHandler, countdownCloseable, stdOut );
worker = channelFuture.get();
verifySessionId();
{code}
I am not saying that this is a solution, I am just explaining that somehow it
seems to help to make {{Future::get}} return something instead of hanging.
After accepting the connection, the JVM with verbose class-loader logging or
with a chatty Java agent starts writing to the console before the fork channel
is fully initialised. This somehow messes things up. Maybe you know that
already, but I hope it helps, being an additional piece of information, a
little new piece in this jigsaw puzzle - nothing more and nothing less.
For me this works beautifully with {{-verbose:class}} and the simple unit test.
If I try with the Java agent, it prints a lot, but at some point also hangs -
maybe because the my example Java agent makes things a bit more difficult for
Surefire, intentionally also logging on {{stdErr}}, not just on {{stdOut}} like
the class-loading logger. Maybe there we have a similar race condition because
the forked VM logs into a stream which is not fully initialised and ready to be
read in the parent VM after the socket connection is already open. I am too
busy to investigate that part now, but I hope that this helps a bit in order to
craft a stable solution for this issue.
> 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)
