Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Date: Fri, 11 Nov 2016 10:27:58 +0000 (UTC)
From: "Yuriy (JIRA)" <jira@apache.org>
To: issues@maven.apache.org
Message-ID: <JIRA.13019544.1478700686000.253074.1478860078407@Atlassian.JIRA>
In-Reply-To: <JIRA.13019544.1478700686000@Atlassian.JIRA>
References: <JIRA.13019544.1478700686000@Atlassian.JIRA> <JIRA.13019544.1478700686744@arcas>
Subject: [jira] [Commented] (SUREFIRE-1302) The forked VM terminated without
 properly saying goodbye. VM crash or System.exit called?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 11 Nov 2016 10:28:00 -0000


    [ https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15656708#comment-15656708 ] 

Yuriy commented on SUREFIRE-1302:
---------------------------------

Originally there is a situation when the process is killed and there is no any way to configure logic to make it not happen. I would consider this as defect so far. 

By the way according to the http://maven.apache.org/surefire/maven-surefire-plugin/faq.html#vm-termination there is no mention unfortunately about one more case I described above when it might fail. It actually fails and each failure means typically a Problem, therefore as far as there is no way to fix this with configuration of surefire, it could be considered as defect for the module.

I don't think that this is an improvement, because improvement is an extension of already existing and working functionality which brings new opportunities. At this case there is a situation which leads to an incident and error and could't be resolved simply.

> The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
> -----------------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-1302
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.19.1
>            Reporter: Yuriy
>
> 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.4#6332)