Deploying a second WildFly server

This article explains how a second WildFly server can be deployed on a host that already has one running.

Introduction

There are situations where you may wish to deploy a second WildFly server on a host that already has one deployed. One reason for this would be to test out the transfer of files between development SPADE deployments while not interferring with production deployments of that application. Another reason would be to test out file transfers between SPADE deployments but do not have a second machine on which you can run that test. Whatever the reason, here is a quick explanation of how you can set up a second WildFly server instance.

Cloning portions of an Existing WildFly server

While it is possible to do a complete second installation of the WildFly server distribution, only a few pieces need to be cloned in order to get a second instance running. In this section you will clone those parts and in the sections after this you'll learn which files need to be modified and how. If you are doing a complete second installation you can skip this section amd move straight on to the next section in order to modify that installation.

For a separate WildFly server you need to clone the following;

  • the server's individual directory;
  • the server's service files;
  • the server's start up script;

The following commands do this:

export ALT_LABEL=".2"
cd ~/server/wildfly-8.2.0.Final
cp -rp standalone standalone${ALT_LABEL}
cd bin/init.d/
cp -rp wildfly.conf wildfly${ALT_LABEL}.conf
cp -rp wildfly-init-redhat.sh wildfly${ALT_LABEL}-init-redhat.sh
cd ..
cp -rp standalone.sh standalone${ALT_LABEL}.sh
cd
cp -rp ~/bin/wildfly ~/bin/wildfly${ALT_LABEL}

Modifying the standalone.xml configuration file

Once the contents of a new deployment has been created, either by cloing an existing installation or created a brand new one, a number of key files need to be modified in order to avoid the new WildFly server interferring with the original one.

To begin with the standalone.xml configuration file need to be modified in order to use different network ports. The following commands show how this can be done for a server cloned from a default installation already customized to support a SPADE deployment (See this article).

export ALT_LABEL=".2"
export PORT_OFFSET=100
cd ~/server/wildfly-8.2.0.Final/
cat > patch_1.txt << EOF
*** standalone/configuration/standalone.xml      2014-08-12 15:55:52.285421400 -0400
--- standalone.2/configuration/standalone.xml    2014-08-12 17:31:02.604723626 -0400
***************
*** 94,100 ****
          <subsystem xmlns="urn:wildfly:domain:datasources:1.0">
              <datasources>
                  <datasource jndi-name="java:wildfly/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
!                     <connection-url>jdbc:h2:~/spade/h2/spade;DB_CLOSE_DELAY=-1</connection-url>
                      <driver>h2</driver>
                      <security>
                          <user-name>sa</user-name>
--- 94,100 ----
          <subsystem xmlns="urn:wildfly:domain:datasources:1.0">
              <datasources>
                  <datasource jndi-name="java:wildfly/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
!                     <connection-url>jdbc:h2:~/spade${ALT_LABEL}/h2/spade;DB_CLOSE_DELAY=-1</connection-url>
                      <driver>h2</driver>
                      <security>
                          <user-name>sa</user-name>
***************
*** 286,292 ****
          </interface>
      </interfaces>
  
!     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="\${wildfly.socket.binding.port-offset:0}">
          <socket-binding name="management-native" interface="management" port="\${wildfly.management.native.port:9999}"/>
          <socket-binding name="management-http" interface="management" port="\${wildfly.management.http.port:9990}"/>
          <socket-binding name="management-https" interface="management" port="\${wildfly.management.https.port:9443}"/>
--- 286,292 ----
          </interface>
      </interfaces>
  
!     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="\${wildfly.socket.binding.port-offset:${PORT_OFFSET}}">
          <socket-binding name="management-native" interface="management" port="\${wildfly.management.native.port:9999}"/>
          <socket-binding name="management-http" interface="management" port="\${wildfly.management.http.port:9990}"/>
          <socket-binding name="management-https" interface="management" port="\${wildfly.management.https.port:9443}"/>
EOF
unset PORT_OFFSET
patch standalone${ALT_LABEL}/configuration/standalone.xml patch_1.txt
rm patch_1.txt
cd -

The most important modification is to set a non-zero value for the port-offset attribute (multiples of 100 work well here). The above command also changes the location used to store the ExampleDS database. Exactly what changes need to be made depends on how much the standalone.xml file has been customized.

Modifying the wildfly.conf service file

The wildfly.conf service file needs to be modified so that the console log and process id files are stored in a new locations. The following commands show how this can be done for a server cloned from a default installation already customized to support a SPADE deployment (See this article).

export ALT_LABEL=".2"
cd ~/server/wildfly-8.2.0.Final/
cat > patch_2.txt << EOF
*** bin/init.d/wildfly.conf      1969-12-31 16:00:00.000000000 -0800
--- bin/init.d/wildfly.2.conf    1969-12-31 16:00:00.000000000 -0800
*************** SHUTDOWN_WAIT=30
*** 34,41 ****
  
  ## Location to keep the console log
  # JBOSS_CONSOLE_LOG="/var/log/wildfly/console.log"
! JBOSS_CONSOLE_LOG=\${JBOSS_HOME}/standalone/log/console.log
  
  # Location of JBoss PID file
  #
! JBOSS_PIDFILE=\${JBOSS_HOME}/standalone/jboss-as-standalone.pid
--- 34,41 ----
  
  ## Location to keep the console log
  # JBOSS_CONSOLE_LOG="/var/log/wildfly/console.log"
! JBOSS_CONSOLE_LOG=\${JBOSS_HOME}/standalone${ALT_LABEL}/log/console.log
  
  # Location of JBoss PID file
  #
! JBOSS_PIDFILE=\${JBOSS_HOME}/standalone${ALT_LABEL}/wildfly-standalone.pid
EOF
patch bin/init.d/wildfly${ALT_LABEL}.conf patch_2.txt
rm patch_2.txt
cd -

Modifying the wildfly-standalone.sh service file

The wildfly-standalone.sh service file need to be modified so that it uses the new script file. The following commands show how this can be done for a server cloned from a default installation already customized to support a SPADE deployment (See this article).

export ALT_LABEL=".2"
cd ~/server/wildfly-8.2.0.Final/
cat > patch_3.txt << EOF
*** bin/init.d/wildfly-init-redhat.sh     1969-12-31 16:00:00.000000000 -0800
--- bin/init.d/wildfly.2-init-redhat.sh   1969-12-31 16:00:00.000000000 -0800
*************** fi
*** 56,62 ****
  
  # Startup mode script
  if [ "\$JBOSS_MODE" = "standalone" ]; then
! 	JBOSS_SCRIPT=\$JBOSS_HOME/bin/standalone.sh
  	if [ -z "\$JBOSS_CONFIG" ]; then
  		JBOSS_CONFIG=standalone.xml
  	fi
--- 56,62 ----
  
  # Startup mode script
  if [ "\$JBOSS_MODE" = "standalone" ]; then
! 	JBOSS_SCRIPT=\$JBOSS_HOME/bin/standalone${ALT_LABEL}.sh
  	if [ -z "\$JBOSS_CONFIG" ]; then
  		JBOSS_CONFIG=standalone.xml
  	fi
EOF
patch bin/init.d/wildfly${ALT_LABEL}-init-redhat patch_3.txt
rm patch_3.txt
cd -

Modifying the standalone.sh script file

The standalone.sh script file need to be modified so that it uses the new base directory. The following commands show how this can be done for a server cloned from a default installation already customized to support a SPADE deployment (See this article).

export ALT_LABEL=".2"
cd ~/server/wildfly-8.2.0.Final/
cat > patch_4.txt << EOF
*** bin/standalone.sh       1969-12-31 16:00:00.000000000 -0800
--- bin/standalone.2.sh     1969-12-31 16:00:00.000000000 -0800
*************** fi
*** 164,170 ****
  
  # determine the default base dir, if not set
  if [ "x\$JBOSS_BASE_DIR" = "x" ]; then
!    JBOSS_BASE_DIR="\$JBOSS_HOME/standalone"
  fi
  # determine the default log dir, if not set
  if [ "x\$JBOSS_LOG_DIR" = "x" ]; then
--- 164,170 ----
  
  # determine the default base dir, if not set
  if [ "x\$JBOSS_BASE_DIR" = "x" ]; then
!    JBOSS_BASE_DIR="\$JBOSS_HOME/standalone${ALT_LABEL}"
  fi
  # determine the default log dir, if not set
  if [ "x\$JBOSS_LOG_DIR" = "x" ]; then
EOF
patch bin/standalone${ALT_LABEL}.sh patch_4.txt
rm patch_4.txt
cd -

Modifying the ~/bin/wildfly script file

The wildfly-standalone.sh service file need to be modified so that it used the new script file. The following commands show how this can be done for a server cloned from a default installation already customized to support a SPADE deployment (See this article).

export ALT_LABEL=".2"
cd ~/bin
cat > patch_5.txt << EOF
*** wildfly       1969-12-31 16:00:00.000000000 -0800
--- wildfly.2     1969-12-31 16:00:00.000000000 -0800
***************
*** 9,14 ****
  # config: ${HOME}/server/wildfly-8.2.0.Final/bin/init.d/wildfly.conf
  
  JBOSS_INIT_D=${HOME}/server/wildfly-8.2.0.Final/bin/init.d
! JBOSS_CONF="\${JBOSS_INIT_D}/wildfly.conf"
  export JBOSS_CONF
! \${JBOSS_INIT_D}/wildfly-init-redhat.sh \$*
--- 9,14 ----
  # config: ${HOME}/server/wildfly-8.2.0.Final/bin/init.d/wildfly.conf
  
  JBOSS_INIT_D=${HOME}/server/wildfly-8.2.0.Final/bin/init.d
! JBOSS_CONF="\${JBOSS_INIT_D}/wildfly${ALT_LABEL}.conf"
  export JBOSS_CONF
! \${JBOSS_INIT_D}/wildfly${ALT_LABEL}-init-redhat.sh \$*
EOF
patch wildfly${ALT_LABEL} patch_5.txt
rm patch_5.txt
cd -

Running the New WildFly server

Before starting the new WildFly server instance you should opena second window and run the following commands in order to see the log file.

export ALT_LABEL=".2"
touch  ~/server/wildfly-8.2.0.Final/standalone${ALT_LABEL}/log/console.log
tail -f ~/server/wildfly-8.2.0.Final/standalone${ALT_LABEL}/log/console.log

Now, in your original window you can start the new server with the following commands and watch it start by looking at the log file.

export ALT_LABEL=".2"
wildfly${ALT_LABEL} start

Nautually you can stop it with the following command.

wildfly${ALT_LABEL} stop

NOTE: You should not deploy the "vanilla" SPADE application in this server as it will pick up the defaiult configration used by the standard SPADE instance. Information about how to change the configuration used by a SPADE applicaiton is documented elsewhere.