Code Server's Process Still Running After Stopping the maven launcher ( CTRL + C )

[zouabimourad]

Hi,

When i launch mvn gwt:codesever 3 process are started ( maven jvm , cmd and codesever jvm )

When I Stop mvn .. the 2 first process are stopped but the codeserver jvm is still running

Regards.

[zouabimourad]

Same thing when i stop gwt compilation .. the leaf java process ( gwt compiler process ) is still running ...

[tbroyer]

I've been a Linux user for years and I don't have any expertise on Windows idiosyncrasies.

Patches welcome!

[zouabimourad]

I have the same problem with the 1.8.2 version of the legacy plugin but the 1.8.1 is ok

I will try to fix it.

[tbroyer]

It might be due to an update of the plexus-utils dependency (from 3.0.16 to 3.1.0 between org.codehaus.mojo:gwt-maven-plugin 2.8.1 and 2.8.2; and from 3.0.21 to 3.1.0 in net.ltgt.gwt.maven:gwt-maven-plugin 1.0-rc-9 compared to previous versions). You should be able to test with earlier versions of plexus-utils by declaring them in the plugin's dependencies:

<plugin>
  <groupId>net.ltgt.gwt.maven</groupId>
  <artifactId>gwt-maven-plugin</artifactId>
  <version>1.0-rc-9</version>
  <dependencies>
    <dependency>
      <groupId>org.codehaus.plexus</groupId>
      <artifactId>plexus-utils</artifactId>
      <version>3.0.16</version>
    </dependency>
  </dependencies>
</plugin>

If that fixes it for you, then we'd have at least a lead to explore and possibly report it to plexus-utils (if that doesn't fix it though, it might be that the dependency is not taken into account; run Maven with -X –debug logs– and look for the plugin's class world/realm to see what's actually used)

[zouabimourad]

It works fine with the dependency override. There is no a cmd process between maven's JVM and Codeserver's JVM anymore .. and after Exit all the JMVs are Stopped. Thx !

[tbroyer]

Let's keep it open please. You have a workaround, but this still needs fixing (even if that only means waiting for a new version of plexus-utils with a fix and upgrading to it; or temporarily downgrading)

[jjYBdx4IL]

Easiest solution would be to use jetty's stopPort if possible.

If that's not possible, a cross-platform library to kill processes by port number would be in order. (win10/linux: netstat, win10: tasklist+taskkill, linux; kill)

Here is a quick and dirty solution I used in one of my projects:

https://github.com/jjYBdx4IL/example-maven-project-setups/blob/master/gwt-example/devel-it/src/main/resources/startStop.sh

But it is mixed with Linux where I simply put an environment variable into the started process and then identify the process using that unique tag. That's not possible under Windows it seems.

However, I should note that GWT dev mode does not work too well under Windows anyways because it seems that it sometimes has a race condition where the strict file locking on Windows produces a file access conflict with itself.

Maybe it's possible to NOT FORK the codeserver and run it inside the main maven process, at least when using the @default-cli execution? Or attach the forked process' resources to the parent process such that a termination of the parent leads to the termination of the child somehow?

[jjYBdx4IL]

Adding

  <plugin>
    <groupId>net.ltgt.gwt.maven</groupId>
    <artifactId>gwt-maven-plugin</artifactId>
    <configuration>
      <systemProperties>
        <STOP.PORT>9999</STOP.PORT>
        <STOP.KEY>GWTCODESERVER</STOP.KEY>
      </systemProperties>
    </configuration>
  </plugin>

allows to shut down a stray codeserver by sending the key to the stop port:

java -jar ./jetty-distribution-9.4.14.v20181114/start.jar -DSTOP.PORT=9999 -DSTOP.KEY=GWTCODEGSERVER--stop

So I recommend setting the stop port by default with a default key value and checking the port connectivity before trying to start the codeserver.

Also, on Windows the codeserver is likely to keep locking files in target/ when using CTRL-C. Not sure how to go about this. Probably, there should be a gwt:stop command that is tied to the pre-clean phase by default.

[jjYBdx4IL]

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4717969

a shutdown hook would at least solve the CTRL-C issue on Windows:

        final ProcessBuilder pb =
            new ProcessBuilder("java", "ControlCProblemDemo");
            final Process p = pb.start();
        Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
            
            @Override
            public void run() {
                System.out.println("killing it");
                p.destroyForcibly();
            }
        }));

[tbroyer]

There is such a shutdown hook already, with the exception that it calls destroy() rather than destroyForcibly() (plexus-utils is likely to have/want to support old JVMs though, and destroyForcibly()w as added in 1.8).
https://github.com/codehaus-plexus/plexus-utils/blob/plexus-utils-3.1.1/src/main/java/org/codehaus/plexus/util/cli/CommandLineUtils.java#L134-L152
That being said, on Windows, destroyForcibly() just calls destroy():
https://github.com/unofficial-openjdk/openjdk/blob/2357b5fc925a96e53e6e9a84230be327424ad1ce/src/java.base/windows/classes/java/lang/ProcessImpl.java#L553-L557

IOW, what you're proposing is already there.

On Windows, a workaround might be to use gwt:devmode with <devmodeArg>-noserver</devmodeArg>; that way you can easily stop the code server by closing the devmode window.