jettyRun tasks automatically closes when run on IntelliJ IDEA

[mrichardsonjr]

When running Gretty's jettyRun task from IntelliJ IDEA, it gets all the way to the line "Press any key to stop the jetty server.", and then the server just stops and prints out "Jetty server stopped.", even though I have not pressed any keys. Perhaps IntelliJ is automatically feeding the process input? In any event, could we configure the jettyRun task so that not just any input will cause it to stop?

[akhikhl]

Um, I did not try it in IntelliJ IDEA yet. Maybe jettyStart is more convenient for your purposes? It does not stop on "any key", it waits for stop signal from another process (supposedly, gradle jettyStop). If jettyStart is not convenient for you, can you suggest "ideal way", how it should work under IntelliJ IDEA? I will see to implementing it, of course.

[akhikhl]

I tried it in IntelliJ IDEA. Yes, "press any key" does not work - console application just proceeds. To isolate the problem, I tried the following code from IntelliJ IDEA + Gradle:

task ask << {
  println('> Please enter a line: ')
  BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(System.in))
  String line = bufferedReader.readLine()
  println "You entered: $line"
}

When you run gradle ask, line is always null and program does not wait for user input. I also tried System.console() - it is always null.

So, it seems to be a problem with IntelliJ IDEA Gradle integration, not with Gretty plugin.

As a workaround I recommend using jettyStart and jettyStop tasks.

[obstschale]

Thx! I just experienced the same misbehavior. But your proposed work-around works just fine :+1:

[mrichardsonjr]

Thanks, I've tried using the jettyStart & jettyStop, but I've noticed a strange behavior though. When starting jettyStart using the gradle plugin on IntelliJ and then doing a jettyStop, if I click CTRL-ALT-DELETE and look at the running processes in Windows, the process is still hanging around. Which is fine, but odd that this doesn't happen if I just use the command line. The annoying part is that if I accidentally click "jettyStart" while jetty is already running in IntelliJ, it fails, but it leaves the program is some kind of inconsistent state. If I click jetty stop, it only kills one of the processes, but not the other, even if I click jettyStop twice. If I click jettyStart, I get a "java.net.BindException: Address already in use: JVM_Bind" error. But clicking JettyStop fails by giving me a "Connection refused: connect" error. I basically have to manually kill the process by doing a CTRL-ALT-DELETE. So as a workaround, I've been just using the command line and using jettyRun, but it'd be really nice to run from the IDE.

[akhikhl]

Thank you for reporting. I'll have a look at the problem.

[akhikhl]

Hello colleagues,

Sorry for delay, I was on vacation.

I redesigned Gretty part dealing with start/stop. Now it gracefully handles attempts to start Gretty (with the same ports) twice. There should be no hanging processes left.

Could you, please, test it? The redesign is not released yet, it is available in snapshot version only. Please use the following script to configure gradle to use Gretty snapshot version:

buildscript {
  repositories {
    jcenter()
    maven { url 'http://oss.jfrog.org/artifactory/oss-snapshot-local' }
  }

  dependencies {
    classpath 'org.akhikhl.gretty:gretty:1.1.2-SNAPSHOT'
  }
}

apply plugin: 'war'
apply plugin: 'org.akhikhl.gretty'

I'm looking forward to your feedback.

[akhikhl]

You would still need appStart/appStop (or jettyStart/jettyStop, tomcatStart/tomcatStop) within IDE. xxxRun tasks would not work because of console problems I described earlier in this thread.

[mrichardsonjr]

Thanks very much for looking at this. jettyStart and jettyStop work fine on the command line. However if I run jettyStart and then jettyStop on IntelliJ Idea, it leaves behind 2 java processes. After 2 minutes or so, the 2 processes automatically close. I'm not getting the java.net.BindException anymore, so I suppose it's usable. However, it's strange behavior -- I'm hoping it doesn't cause any issues.

[akhikhl]

Hanging java processes are probably due to Gradle daemon, but I am not sure. Will have to reproduce it again on IJ and have a look where the source of the problem is.

[CannyDuck]

Are there any news for the haning java processes?

[akhikhl]

Yes, I researched java processes with IJ + Gretty. Here are the results.

After start of IJ, but before running any Gretty tasks two java processes:

ahi@ahi-home:~$ ps aux | grep java | grep -v grep
ahi      12882 47.5  6.5 3347180 522180 ?      Sl   23:16   1:20 /usr/lib/jvm/java-8-oracle/bin/java -Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -ea -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Djsse.enableSNIExtension=false -XX:+UseCodeCacheFlushing -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=50 -Dawt.useSystemAAFontSettings=lcd -Djb.vmOptionsFile=/home/ahi/devtools/idea/bin/idea64.vmoptions -Xbootclasspath/a:/home/ahi/devtools/idea/bin/../lib/boot.jar -Didea.paths.selector=IdeaIC13 -Djb.restart.code=88 com.intellij.idea.Main
ahi      12946 27.0  6.8 3508324 546388 ?      Sl   23:17   0:40 /usr/lib/jvm/java-8-oracle/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /home/ahi/.gvm/gradle/2.1/lib/gradle-launcher-2.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 2.1 /home/ahi/.gradle/daemon 10800000 f1d075c4-9bd0-4c35-b4d7-bb35282607bc -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant

the first process is IJ IDE itself, the second process is gradle daemon. I guess IJ starts gradle daemon as soon as it accesses gradle configuration.

after appStart task three java processes:

ahi@ahi-home:~$ ps aux | grep java | grep -v grep
ahi      12882 42.6  6.6 3349228 527532 ?      Sl   23:16   1:30 /usr/lib/jvm/java-8-oracle/bin/java -Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -ea -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Djsse.enableSNIExtension=false -XX:+UseCodeCacheFlushing -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=50 -Dawt.useSystemAAFontSettings=lcd -Djb.vmOptionsFile=/home/ahi/devtools/idea/bin/idea64.vmoptions -Xbootclasspath/a:/home/ahi/devtools/idea/bin/../lib/boot.jar -Didea.paths.selector=IdeaIC13 -Djb.restart.code=88 com.intellij.idea.Main
ahi      12946 24.5  7.3 3522840 580752 ?      Sl   23:17   0:47 /usr/lib/jvm/java-8-oracle/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /home/ahi/.gvm/gradle/2.1/lib/gradle-launcher-2.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 2.1 /home/ahi/.gradle/daemon 10800000 f1d075c4-9bd0-4c35-b4d7-bb35282607bc -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant
ahi      13229  105  2.3 4448592 184648 ?      Sl   23:20   0:07 /usr/lib/jvm/java-8-oracle/bin/java -Djava.security.egd=file:/dev/./urandom -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-continuation/9.2.3.v20140905/f714349a13468467ba1dd461df1d947543c9906a/jetty-continuation-9.2.3.v20140905.jar:/home/ahi/.m2/repository/org/akhikhl/gretty/gretty-runner-jetty9/1.1.5-SNAPSHOT/gretty-runner-jetty9-1.1.5-SNAPSHOT.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-commons/5.0.3/a7111830132c7f87d08fe48cb0ca07630f8cb91c/asm-commons-5.0.3.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-jsp/9.2.3.v20140905/9cba8b25c9fd08bc55889fe9eb77838de0ea887/jetty-jsp-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-annotations/9.2.3.v20140905/5d161d4c49eb53914fcf4ac1a3178a1c7346e9da/jetty-annotations-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm/5.0.3/dcc2193db20e19e1feca8b1240dbbc4e190824fa/asm-5.0.3.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.3.v20140905/d97a5394990b8c7fce2d35e68543c8f9faedca55/jetty-server-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-webapp/9.2.3.v20140905/43095b0eaf3144044285594991bbb265e67d3664/jetty-webapp-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-servlet/9.2.3.v20140905/c063fd522fa7110b7916a77c9aa5652065bb8bf3/jetty-servlet-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-security/9.2.3.v20140905/d4e73264bd2dc327025069e49a23cb781800c02f/jetty-security-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-plus/9.2.3.v20140905/ffe0f3d43f92aa8953d14dfda2e0fc80d24508a9/jetty-plus-9.2.3.v20140905.jar:/home/ahi/.m2/repository/org/akhikhl/gretty/gretty-runner-jetty/1.1.5-SNAPSHOT/gretty-runner-jetty-1.1.5-SNAPSHOT.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/javax.servlet/javax.servlet-api/3.1.0/3cd63d075497751784b2fa84be59432f4905bf7c/javax.servlet-api-3.1.0.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.ow2.asm/asm-tree/5.0.3/287749b48ba7162fb67c93a026d690b29f410bed/asm-tree-5.0.3.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty.toolchain/jetty-schemas/3.1.M0/6179bafb6ed2eb029862356df6713078c7874f85/jetty-schemas-3.1.M0.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/javax.servlet.jsp/javax.servlet.jsp-api/2.3.1/95c630902565feda8155eb32d46064ef348435fc/javax.servlet.jsp-api-2.3.1.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.glassfish.web/javax.servlet.jsp/2.3.2/613f624102267b1397e845b3181a72273bd6f399/javax.servlet.jsp-2.3.2.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty.orbit/javax.servlet.jsp.jstl/1.2.0.v201105211821/db594f1c8fc00d536f6d135bd7f8a9a99a6b8eea/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.glassfish.web/javax.servlet.jsp.jstl/1.2.2/5b2e83ef42b4eef0a7e41d43bb1d4b835f59ac7a/javax.servlet.jsp.jstl-1.2.2.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty.orbit/org.eclipse.jdt.core/3.8.2.v20130121/ebb04771ae21dec8682e4153e97404d9933a9c13/org.eclipse.jdt.core-3.8.2.v20130121.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/javax.annotation/javax.annotation-api/1.2/479c1e06db31c432330183f5cae684163f186146/javax.annotation-api-1.2.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-http/9.2.3.v20140905/455d59ae94ca0dbb26412395e6db62c2b5df1150/jetty-http-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-io/9.2.3.v20140905/2a4003a81ac95f29764a353ba7c5f5a40c3cee60/jetty-io-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-xml/9.2.3.v20140905/5906f2bdf40bd724d61153aca3f0596167c99081/jetty-xml-9.2.3.v20140905.jar:/home/ahi/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-jndi/9.2.3.v20140905/d469a986b7dc401e1f314c4d0004e4681f3ced6c/jetty-jndi-9.

the first and second processes are the same (IJ and gradle daemon), the third process is a web-application.

After appStop task three java processes:

ahi@ahi-home:~$ ps aux | grep java | grep -v grep
ahi      12882 35.6  6.8 3351276 545316 ?      Sl   23:16   1:37 /usr/lib/jvm/java-8-oracle/bin/java -Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -ea -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Djsse.enableSNIExtension=false -XX:+UseCodeCacheFlushing -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=50 -Dawt.useSystemAAFontSettings=lcd -Djb.vmOptionsFile=/home/ahi/devtools/idea/bin/idea64.vmoptions -Xbootclasspath/a:/home/ahi/devtools/idea/bin/../lib/boot.jar -Didea.paths.selector=IdeaIC13 -Djb.restart.code=88 com.intellij.idea.Main
ahi      12946 19.1  7.4 3522840 593916 ?      Sl   23:17   0:48 /usr/lib/jvm/java-8-oracle/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /home/ahi/.gvm/gradle/2.1/lib/gradle-launcher-2.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 2.1 /home/ahi/.gradle/daemon 10800000 f1d075c4-9bd0-4c35-b4d7-bb35282607bc -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant
ahi      13378 76.5  4.0 3495052 319328 ?      Sl   23:20   0:19 /usr/lib/jvm/java-8-oracle/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /home/ahi/.gvm/gradle/2.1/lib/gradle-launcher-2.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 2.1 /home/ahi/.gradle/daemon 10800000 f5b86863-a9f5-4d06-b1cd-14ef7307d412 -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant

the first and second processes are the same (IJ and gradle daemon), the third process is a new gradle daemon. Apparently, gradle starts a new daemon if an existing daemon is busy (this is the case with appStart task).

So, my conclusion: Gretty accurately closes it's own java process (web-application). Other processes are part of IJ and Gradle infrastructure, so we should not worry.

[rit001]

I am also seeing this same issue when I try and place a gretty based application into a systemd service by running akhikhl.gretty.GrettyStarter from a .service file. The application is started, the 'Press any key to stop the server' message is logged and akhikhi.gretty.LauncherBase reports 'Sending command: stop'.

[akhikhl]

@rit001, are you using Gretty-generated product? Exactly what command do you place under systemd? I would recommend using "start.sh", not "run.sh".

[rit001]

Hi, thanks for the quick reply.

Your comment is at least helping me to understand what I need to look at. It seems that systemd is parsing the Exec line and striping parts of it. So if I place the java command on the Exec line it defaults to run rather than start (this I now understand) as the start parameter gets lost.

To get past this I now Exec the script, and can now move on to other issues that I do not yet understand.

On side note. all the generated scripts (run.sh, start.sh, etc) are all missing a final CR which means when viewing them via commands like cat you can end up with the shell prompt ends up at the end of the last line.

[akhikhl]

Again, question: are you using Gretty-generated product? This can greatly save your time.

[rit001]

Sorry I forgot to answer that.

Yes I am working from a bundled application that has been produced via the Gretty generator. So to run it from a command line I would use run.sh or start.sh

[akhikhl]

This is how scripts are supposed to be used: run.sh is an interactive script. It is to be stopped by a keypress. It's not suitable for starting with OS. start.sh is non-interactive script. It can be only stopped by stop.sh. It suits for starting with OS.

[rit001]

The problem seems to be caused with parameter passing and the fact that the start script is only a start script if the 'start' parameter is correctly processed, otherwise the default seems to be 'run'

If I run ./start.sh
The result is that my application is run and the end message is "Run './stop.sh' to stop the server

If I run ./start.sh -DLocalDb_Driver=com.mysql.jdbc.Drive The result is that my application is run and the end message is "Press any key to stop the server"

If I change start.sh so that the java line ends "start $@" rather than "$@ start" I can overcome this issue but as this file is a generated and packaged file I have to make changes post installation.

[akhikhl]

Please read this part of the documentation: http://akhikhl.github.io/gretty-doc/Runner-arguments.html

Try:

./start.sh --runnerArg=-DLocalDb_Driver=com.mysql.jdbc.Drive

There's no need to change order of arguments in the shell script.

[just-boris]

Reported the issue to IDEA bugtracker, to make its developers aware about this problem: https://youtrack.jetbrains.com/issue/IDEA-164654

[mvysny]

I just tried to print System.in.read() in the ask task; in Intellij it prints -1 which means End-Of-Stream. So apparently Intellij offers an empty System.in to Gradle. I will add this information to the Intellij bug.