[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1302:
-----------------------------------
Are you open for testing SNAPSHOT version in several days?
{quote}
I though you meant that in a future version, the GC logs would be in
TEST-null.txt.
{quote}
I am not able to distinguish between GC logs and other. Writing to native
System stream std/out is a corruption from our point of view. We did
everything to bypass this when we call {{System.setOut()}} in Surefire. We
override default PrintStream, wrap your custom logs, encode controlling
data in to it. If JVM or user writes to native stream the plugin may behave
wrong and hang which is in our evidence that we have blocker and critical
issues in Jira. So from my point of view this is user error. In the future
we want to avoid this completely by using sockets and not this mechanism.
On Tue, May 9, 2017 at 9:31 AM, Olivier Peyrusse (JIRA) <j...@apache.org>
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> ------------------------------------------------------------------------------
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
> Affects Versions: 2.19.1
> Reporter: Yuriy Zaplavnov
> Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments:
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture<?> listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
> 0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
