Creating a Java virtual machine

TIBCO ActiveSpaces® Transactions nodes support running multiple Java Virtual Machines. The number of JVMs started is application specific.

JVMs are created using the deployment tool described in the section called “Deployment tool”.

Deployment tool

Java Virtual Machines are created using the TIBCO ActiveSpaces® Transactions deployment tool which is packaged in the deploy.jar file located in the TIBCO ActiveSpaces® Transactions SDK. The deployment tool supports these general forms:

java [local JVM options] -jar deploy.jar [options] <target> [application parameters]

java [local JVM options] -jar deploy.jar [options] help

A complete reference for the deployment tool options can be found in the TIBCO ActiveSpaces® Transactions Java Developer's Guide or using the help command. The deployment tool supports two modes when starting a JVM to execute application code. These modes are controlled with the detach option to the deployment tool. The modes are:

  • Detached - detach = true

  • Attached - detach = false

The behavior of the deployment tool in detached mode depends on the value of the <target> parameter. If the <target> parameter is a fully scoped name of a main method to execute in the JVM, all Java classes must be available on the server in a deployment directory. If the <target> parameter is an archive file, e.g. a JAR, the archive is copied to the node before starting the JVM.

The deployment tool returns to the caller after starting a JVM, executing the main method, and then waiting for application startup status for detachtimeout seconds, where detachtimeout is a deployment tool option. If the application exits with an error before the detachtimeout period expires, an error is returned to the deployment tool. If the detachtimeout period expires and the application is still running, success is returned to the deployment tool. Detached mode is recommended for deployment of production systems.

[Warning]

When using detached mode with a main method <target>, all classes must be available on the server. If they are not available program execution will fail with a java.lang.NoClassDefFoundError.

Attached mode supports both a JAR file, or a fully scoped name of a main method, in the <target> parameter. The JAR or class specified on the command line is copied to the server before the JVM is started. The JVM is started and the main method is executed. The deployment tool continues to block waiting for the JVM to exit. While the JVM is active, class files are shipped to the server from the client if the class is not already available on the server. Attached mode is very useful during development to support transparent integration with Java IDEs.

To summarize, the following steps are taken by the deployment tool:

  1. Archive or class file (attached mode only) specified in the <target> parameter is copied to the node.

  2. The JVM is started.

  3. Specified main method is executed.

  4. In detached mode the deployment tool returns to the caller, in attached mode it blocks waiting for the JVM to exit

When the deployment tool is running in attached mode, keep-alive messages are continuously sent between the deployment tool and all application nodes. If an application node does not receive a keep-alive message from the deployment tool within a configurable amount of time (keepaliveseconds option to the deployment tool) the node terminates the JVM running the application. This ensures that applications running in attached mode are not abandoned if there are client or network errors. Keep-alive messages are not used when the application is deployed in detached mode.

Example 4.1, “Simple application” shows a simple application that starts a daemon thread and then returns from main.

Example 4.1. Simple application

//     $Revision: 1.1.2.1 $

package com.kabira.snippets.vmlifecycle;

/**
 *  Using daemon threads 
 * <p>
 * <h2> Target Nodes</h2>
 * <ul>
 * <li> <b>domainnode</b> = A
 * </ul>
 */
public class Daemon 
{
    /**
     * Application thread
     */
    public static class MyThread extends Thread
    {
         @Override
         public void run()
         {
              try
              {
                   System.out.println("thread sleeping...");

                   Thread.sleep(5000);
              } 
              catch (InterruptedException ex)
              {
                   //     Handle exception
              }
         }
    }
    
    /**
     * Main entry point
     * @param args  Not used
     */
    public static void main(String[] args)
    {
          //
          //     Create a new thread
          //
          MyThread     t = new MyThread();

          //
          //     Mark the thread as a daemon thread
          //
          t.setDaemon(true);

          //
          //     Start the thread
          //
          t.run();

          //
          //     Returning from main - causes the JVM to exit
          //
          System.out.println("returning from main");
    }
}

          

This application is deployed to an TIBCO ActiveSpaces® Transactions node with the following command. Notice that the class containing the main method is specified on the command line.

java -jar deploy.jar username=guest password=guest \
     hostname=kabira-server.local adminport=2001 \
     com.kabira.snippets.vmlifecycle.Daemon

INFO: deploy.jar version: [TIBCO TIBCO ActiveSpaces® Transactions
 2.2.0 (build 111214)] starting at [Fri Dec 16 07:30:53 PST 2011]
INFO: JVM remote debugger agent running on [kabira-server.local:41895] ...
INFO: node version: [TIBCO TIBCO ActiveSpaces® Transactions
 2.2.0 (build 111214)]
INFO: Starting application [com.kabira.snippets.vmlifecycle.Daemon] ...
INFO: AST component [com.kabira.snippets.vmlifecycle.Daemon] started on JVM [com_kabira_snippets_vmlifecycle_Daemon10].
WARNING: loopback ip address choosen, this agent may not connect to remote agents
ip_address=127.0.0.1 port=50004
Listening for transport dt_socket at address: 41895
INFO: JMX Management Service started at:
   kabira-server:2099
   172.16.208.130:2099
   service:jmx:rmi:///jndi/rmi://kabira-server:2099/jmxrmi
thread sleeping...
returning from main
INFO: Application [com.kabira.snippets.vmlifecycle.Daemon] exited with status [0].

The application is now running in a JVM on the target TIBCO ActiveSpaces® Transactions node.

Setting Java virtual machine options

Virtual machine options are set using command line options to the deployment tool. For example to change the minimum and maximum memory sizes for the JVM being started the following command would be used:

java -jar deploy.jar username=guest password=guest hostname=192.168.71.129 \
     adminport=2001 detach=true -Xms256m -Xmx512m com.kabira.snippets.jvmlifecycle.Daemon

Class resolution

During JVM execution all class files must be available in the node's class path, or resolved using the deployment tool's CLASSPATH when running in attached mode.

When the deployment tool is running in attached mode, the CLASSPATH of the JVM running the deployment tool (deploy.jar) is used to resolve class references if they cannot be resolved in the node's class path.

Deployment directories are used to add JAR files to a node's class path. By default nodes define the deployment directory as:

#
#   Path relative to the node installation directory
#
../../deploy

All JAR files copied into the deploy directory are automatically added to the node's class path. See the section called “Installation” for details on changing the default deployment directory.