Java WS Core Admin Guide

The first major parameters you can adjust are not strictly container parameters, but tweaking the parameters of the JVM in which your container is running can provide significant performance benefits. Each implementation of the JVM has it's own set of parameters which can be modified, however, all JVM's have parameters to change the heap memory usage. By default, the JVM claims 64 MB from the operating system. This will be too small for any real deployment of the container. For a service such as GRAM, which expects to process large numbers of jobs which may exist for an extended period of time, we recommend specifying at least 1024 MB for the maximum heap memory. In addition, you should specify the minimum amount of heap memory your container will use. To set these values for the container, execute this command:

GLOBUS_OPTIONS="-Xms256M -Xmx1024M"
                    

This will tell the virtual machine to claim 256 MB as the minimum heap size and 1024 MB as the maximum heap size. As a general rule of thumb, if you specify more memory, your performance will improve. Of course, this is only the case if your machine has sufficient memory.

In addition, certain JVM implementations have additional parameters which can improve performance. The most notable is in the Sun JVM implementation. Specifying the process to be -server allows the JVM to run in "server" mode. The JVM will typically perform better on CPU intensive tasks (like most GT containers) when in "server" mode. To set this value, add -server to your GLOBUS_OPTIONS variable:

GLOBUS_OPTIONS="$GLOBUS_OPTIONS -server"
                    

The Container parameters also play a significant role in the performance of your container. The main parameters relate to threads.

Setting up threads for a container is as much an art as a science, so here are some guidelines for configuring your container. The number of threads determines how many concurrent requests your container can service. However, just setting this number to a high value is not a good solution, because each thread takes resources. Ideally, you would want to set this number to be equal to the number of processors your machine has, because that would mean that each thread is being serviced all the time (of course, that is assuming that your computer isn't doing anything else, which is never. That's why this is "ideally"). However, unless you are getting only 1 or 2 requests at a time, this will prevent requests from being processed in a timely manner. So, when configuring this value, you will generally want to find a balance between the number of requests you expect to receive and the resources available on the machine. You should usually try to set this value as low as you can. Having said that, if you expect a large number of requests and those requests are either completed quickly or do the work in a separate thread, the default value of 20 maximum threads is usually sufficient. However, in that scenario, you will probably want to set the minimum number of threads to 20 as well. That way you won't take time starting and stopping threads.

So, as a basic rule of thumb, the default thread configuration will be sufficient unless, you a) expect to receive a large number of concurrent requests which can be processed quickly (in which case you should make the minimum and maximum number of threads equal) or b) you will have a low number of concurrent requests that can be processed quickly (in which case, you might consider reducing the maximum number of threads) or c) you have will receive a large number of concurrent requests which take a long time to process (in which case you should increase the maximum number of threads). The third situation listed is definitely not ideal, because it will put a heavy load on the server with no real way to balance it. In this scenario, you should consider passing the processing from your service to the WorkManager. The specific configuration parameters are listed below.

The default Thread settings are as follows:

The connection timeout parameter in the client can also play a role in tuning performance. This is a new feature in the 4.2 release. It allows a client to keep the http connection open to the server across multiple requests. Setting this to a higher value will mean the same connection is used for longer. This can positively impact performance by eliminating some of the overhead involved in connecting to the server. However, this is not a magic bullet, so don't expect to see huge improvements from this parameter. If you have a long running task on the server, you will probably see modest improvement in the time required to actually submit the request to the server, but the latency in your request will likely make that mostly moot. Also, if you keep a connection open, you will be limiting the ability of other clients to connect. So this is a parameter that should be changed carefully, depending on your particular circumstances.

An example of a deployment descriptor for a CounterService:

<service name="CounterService" provider="Handler" use="literal" style="document"> <parameter name="className"
        value="org.globus.wsrf.samples.counter.CounterService"/>
    <parameter name="handlerClass" value="org.globus.axis.providers.RPCProvider"/>
    <parameter name="scope" value="Application"/>
    <wsdlFile>share/schema/core/samples/counter/counter_service.wsdl</wsdlFile>
    <parameter name="allowedMethodsClass" value="com.counter.CounterPortType"/>
    <parameter name="providers" value=" DestroyProvider SetTerminationTimeProvider
        GetRPProvider SubscribeProvider GetCurrentMessageProvider"/>
</service>
                

Services are defined in a <service> element. The "name" attribute of the <service> element defines the remotely accessible name of the service. The service handle will have the form of <hosting environment URL>/foo, where:

The use attribute should be set to literal and the style attribute to document for all WSRF/WSN based services. The configuration information for a service is defined by various <parameter> sub-elements within a <service> element. The configuration item name corresponds to the "name" attribute in a <parameter> sub element, and the value is put as a "value" attribute within the same parameter element.

Please see Custom Deployment for details on Axis Web Services Deployment Descriptor.

An example of a JNDI configuration bit for a CounterService:

 <service name="CounterService"> <resource name="home"
                    type="org.globus.wsrf.samples.counter.CounterHome"> <resourceParams>
                    <parameter> <name>factory</name>
                    <value>org.globus.wsrf.jndi.BeanFactory</value>
                    </parameter> <parameter>
                    <name>resourceClass</name>
                    <value>org.globus.wsrf.samples.counter.PersistentCounter</value>
                    </parameter> <parameter>
                    <name>resourceKeyName</name>
                    <value>{http://counter.com}CounterKey</value>
                    </parameter> <parameter>
                    <name>resourceKeyType</name>
                    <value>java.lang.Integer</value> </parameter>
                    </resourceParams> </resource> </service>

Each service in WSDD should have a matching entry in the JNDI configuration file with the same name. Under each service entry in JNDI different resource objects or entries might be defined. Please see Section 7, “JNDI, Resources and Objects” for details. Each service entry in JNDI should have a resource defined called "home". That resource is the ResourceHome implementation for the service (as specified by the type attribute). Depending on the ResourceHome implementation different options can be configured for the ResourceHome. Currently we have two main base ResourceHome implementations: org.globus.wsrf.impl.ResourceHomeImpl and org.globus.wsrf.impl.ServiceResourceHome.

Note: All "home" resources must specify a factory parameter with org.globus.wsrf.jndi.BeanFactory value.

<resource name="cache" type="org.globus.wsrf.utils.cache.LRUCache">
    <resourceParams>
        <parameter>
            <name>factory</name>
            <value>org.globus.wsrf.jndi.BeanFactory</value>
        </parameter>
        <parameter>
            <name>timeout</name>
            <value>120000</value>
        </parameter>
        <parameter>
            <name>maxSize</name>
            <value>1000</value>
        </parameter>
    </resourceParams>
</resource>
                        

<service name="CounterService">
    <resource name="home" type="...">
        <resourceParams>
            ...
             <parameter>
                <name>cacheLocation</name>
                <value>java:comp/env/services/CounterService/cache</value>
            </parameter>
            ...
        </resourceParams>
    </resource>
    ...
    <resource name="cache" type="org.globus.wsrf.utils.cache.LRUCache">
        ...
    </resource>
</service>
                        

Please always check the Tomcat log files under the <tomcat.dir>/logs directory for any errors or exceptions.

Server side logging can be configured in $GLOBUS_LOCATION/container-log4j.properties, when the container is stand alone container. For tomcat level logging, refer to Logging for Tomcat, . The logger log4j.appender.A1 is used for developer logging and by default writes output to the system output. By default it is set for all warnings in the Globus Toolkit package to be displayed.

Additional logging can be enabled for a package by adding a new line to the configuration file. Example:

   #for debug level logging from org.globus.package.FooClass 
   log4j.category.org.globus.package.name.FooClass=DEBUG
   #for warnings from org.some.warn.package
   log4j.category.org.some.warn.package=WARN
   

Client side logging can be configured in $GLOBUS_LOCATION/log4j.properties. The logger log4j.appender.A1 is used for developer logging and by default writes output to the system output. By default it is set for all warnings in the Globus Toolkit package to be displayed.