Vertx 3.0 Fork process

[Ernesto Valero Marcelo]

Hello group

I checked the Vert.x 3.0 roadmap and I didn't found if Vert.x 3.0 will support to fork a process when you execute an instance of a Vert.x app. We have made our vertx script to fork the process using exec in Linux, but it could be very usefull if the vert.x process could fork itself. It's necessary to hardcode again a new startup script when we develop a new app.

Is it planned to add this functionality in the future? Someone else have this issues too? Someone has found a better workaround to manage this situation?

Thanks!

[Tim Fox]

Can you elaborate a bit more on what you mean?

I.e. what API you are expecting?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ernesto Valero Marcelo]

Hello Tim

We develop applications in Java using Vert.x framework

If we execute just

vertx runmod my.module.my~app~1.0 -conf config.json

The vertx process stay on the prompt and if you leave the remote server, vertx process will die.
1st workaround was using nohup, but for stopping the vertx process was neccesary to kill the vert.x process.
So we started to develop a startup script in order to use it with init and manage the process (start, stop or restart a Vert.x app)
Using the output of a ps-efa | grep vertx, we put the parameters into the script and using /etc/functions we did this script ( I pass you a template that we have generated):

#!/bin/bash
#
#####################################################################################################
# VARIABLES
#####################################################################################################

JAVA_HOME="/usr/local/java/jdk1.7.0_51"
#JVM Parameters of JMX monitoring
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote=<true|false> -Dcom.sun.management.jmxremote.port=<PORT> -Dcom.sun.management.jmxremote.authenticate=<false|true> -Dcom.sun.management.jmxremote.ssl=<true|false> -Djava.rmi.server.hostname=<IP or HOSTNAME>"
VERTX_HOME="/vertx/current"
PROJECT_HOME="/vertx/aplicaciones/es.my.app"
#Path to properties config file
CONFIG_FILE="/properties/myapp/config.json"
#runmod with main module
OPTIONS="runmod es.my.app~platform~1.0 -conf $CONFIG_FILE"

VERTX_OPTS="-Dvertx.langs.java=es.my.app~shared~1.0:es.my.app.shared.GuiceVerticleFactory"

ENVIRONMENT="DES"

RETVAL=0
PIDFILE=/var/local/vertx/my.app.pid
LOGFILE=/dev/null


#####################################################################################################
# END CONFIGURATION SCRIPT
#####################################################################################################


EXEC="exec -a $ENVIRONMENT $JAVA_HOME/bin/java $JAVA_OPTS $VERTX_OPTS -Dvertx.mods=$PROJECT_HOME/mods/ -Djava.util.logging.config.file=$VERTX_HOME/conf/logging.properties \
    -Dvertx.home=$VERTX_HOME -Dvertx.clusterManagerFactory=org.vertx.java.spi.cluster.impl.hazelcast.HazelcastClusterManagerFactory \
    -classpath :$VERTX_HOME/conf:$VERTX_HOME/lib/*:$PROJECT_HOME org.vertx.java.platform.impl.cli.Starter $OPTIONS &> $LOGFILE"

# Source function library.
. /etc/init.d/functions

#####################################################################################################
# MAIN
#####################################################################################################

start() {
    if [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE); then
       echo 'Service already running' >&2
       return 1
        fi
        echo -n $"Starting vertx: "
        daemon "$EXEC &"
        RETVAL=$?
    pidof $ENVIRONMENT > $PIDFILE
}
stop() {
        echo -n $"Shutting down vertx: "
        killproc -p $PIDFILE
    RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f $lockfile
        return $RETVAL
}
restart() {
        stop
        start
}
rhstatus() {
        status -p $PIDFILE "VERTX_$ENVIRONMENT"
        RETVAL=$?
}
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        restart
        ;;
  status)
        rhstatus
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|status}"
        exit 3
esac

exit $?

Using this script, we are able to execute our apps and fork the process. If we need to start, restart o get status, we just execute /etc/init.d/vertxApp <action>

Maybe if vertx should be able to fork the new app instance, could be easier to manage all vert.x apps in some sistem. Something like:

vertx runmod my.module.my~app~1.0 -conf config.json --fork

Is this information enough to clarify what is the expected behavior?

Thank you. Kind regards

[Tim Fox]

You lost me.

I've understood that you have written a script that can stop a vert.x process or start it if it's not already running.

But I don't understand what the --fork flag is supposed to do.

Can you explain what the desired behaviour of that is?

[Ernesto Valero Marcelo]

Hello Tim

I'm sorry if I wasn't clear enough. I will try to show a better example. Thank you for your pattience and your time

I'm working with development team as systems engineer. Dev team needs to be able to start, restart or stop a Vertx app as a daemon process (i.e. httpd) .

If we use a CI system like Jenkins and we execute from Jenkins:

vertx runmod my.module.my~app~1.0 -conf config.json

Jenkins get stuck forever waitng a return value of the command. The return value only will be returned if you stop or kill the application, because vertx runmod doesn't fork the process and still runing forever. Using the scrtipt that I have showed you previously, I get the pid file of the process, and I'm able to start the application as a daemon

The main goal is the way to execute a vertx app as a daemon process

The most close example that I have though is MongoDB with --fork parameter as you can see in their documentation

If vertx is daemon capable, it make easier to integrate it with init or system.d and could be better for manage a vertx app.
Maybe if the API could manage the vertx process using pidfiles like this:

If I execute something like

 vertx runmod my.module.my~app~1.0 --fork my.app.pid

 then could be possible to manage vertx apps with operations like:
Stop vertx app

vertx stopmod my.app.pid

Restart vertx app

vertx restartmod my.app.pid

Let me know if I have clarified the scenario better.

Thank you. Kind regards.

[Cosmic Interloper]

if your doing this inside of bash, try using disown:

[grant@localhost ~]$ vertx run hello.groovy & disown $!

[1] 5934

[grant@localhost ~]$ Succeeded in deploying verticle 

[grant@localhost ~]$ curl http://localhost:8080

<html><body><h1>Hello from vert.x!</h1></body></html>[grant@localhost ~]$ 

[Manuel Jesús Recena Soto]

Hello Ernesto,

I'm using apache-daemon (jsvc) to manage our REST API developed with vertx. (http://app.getlicense.io).

Regards,

--

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Manuel Jesús Recena Soto
Founder, CEO & CTO of klicap - ingeniería del puzle

mobile phone +34 664 000 629
work phone + 34 954 894 322
www.klicap.es | blog.klicap.es

[Ernesto Valero Marcelo]

Hi Cosmic Interliper

Our first approximation was using & nohup that is very simmilar that your solution, but it doesn't let you manage the process like system.d or init. 

Thank you for your information!

[Ernesto Valero Marcelo]

Hello Manuel

Thank you for your recommendation. I will try to study if jsvc could be a good solution for us.

Is jsvc portable? It's used just for create your own process managament script and then you can distribute this script wherever your want without using additional software?

Thank you!

Kind regards

[Cosmic Interloper]

A mor complex example of on JVM process launching and control I can provide here:

https://github.com/cinterloper/Vert.Xecutor/blob/master/src/main/resources/exe.groovy

I use very.executor to async launch arbitrary processes via shellcode and monitor their output

[Cosmic Interloper]

I probably should have just mentioned this:

http://supervisord.org/running.html

[Ernesto Valero Marcelo]

Hello Cosmic Interloper

Thank you for your recomendations.

We thought about using supervisor, but unfortunately, we can't deploy aditional software in our customer's machines :-(

But thank you very much to everybody for your solutions

Kind regards

[Cosmic Interloper]

Isee Well then processBuilder in the jdk should do u fine