1 Service management

Axional Studio provides the shells to start and stop the application and more shells utilities to help to obtain system information.

1.1 Start the service

Use the provided shell script start.sh to start and studio.sh to stop the application

To start the service use the option:

$ cd /home/axs
$ cd studio
$ bin/studio.sh --start

to starts the service setting the JVM parameters for memory.

1.2 Stop the service

By default the stop option is unavailable. To configure it edit the configuration file config.xml and set the parameters:

  • stop.port: the port where the server is attending the stop request.
  • stop.pass: the string (plain without encoding) to authorize the stop.


Setting the stop option


To stop the service run

$ bin/studio.sh --stop

or kill the process if the stop option is not configured or it doesn't take effect

$ bin/studio.sh --kill

2 Tunning JAVA parameters

The file bin/studio_java.properties contains the default values for Java modifiers. So settings like memory, product compatibility options, etc can be adjusted in this file.

2.1 Memory

The -Xms and -Xmx parameters define the minimum and maximum heap sizes, respectively. Since GC occurs when the generations fill up, throughput is inversely proportional to the amount of the memory available. By default, the JVM grows or shrinks the heap at each GC to try to keep the proportion of free space to the living objects at each collection within a specific range.

Memory parameters:

Option Description Default
JAVA_MEM_START This variable contains the size for the -Xms (minimum heap size) -Xms256M
JAVA_MEM_MAX This variable contains the size for the -Xmx (maximum heap size) -Xmx1024M

To size the Java heap see the following recommendation table:

2GB -Xms256M -Xmx1024M
4GB -Xms512M -Xmx2048M
8GB -Xms1024M -Xmx6144M
12GB -Xms1024M -Xmx10240M

For example, in a host with more than 12 GB of RAM, the following line in bin/.studio.env

JAVA_MEM_FLAGS="-Xms256M -Xmx1024M"

should be changed to

JAVA_MEM_FLAGS="-Xms1024M -Xmx10240M"

2.1.1 Common exceptions

Usual issues that can occur with the memory are:

  • OutOfMemory: One common indication of a memory leak is the java.lang.OutOfMemoryError exception. Usually, this error is thrown when there is insufficient space to allocate an object in the Java heap. In this case, The garbage collector cannot make space available to accommodate a new object, and the heap cannot be expanded further. Also, this error may be thrown when there is insufficient native memory to support the loading of a Java class. In a rare instance, a java.lang.OutOfMemoryError may be thrown when an excessive amount of time is being spent doing garbage collection and little memory is being freed. To solve this issue increase 'Java heap space' modifying the arguments -Xms and -Xmx.
  • GC Allocation Failure: The detail message "GC Allocation Failure" indicates that there is an allocation request that is bigger than the available space in young generation. To solve this issue increase the 'Java heap young space' modifying the arguments -XX:NewSize and -XX:MaxNewSize
  • GC Overhead limit exceeded: The detail message "GC overhead limit exceeded" indicates that the garbage collector is running all the time and Java program is making very slow progress. After a garbage collection, if the Java process is spending more than approximately 98% of its time doing garbage collection and if it is recovering less than 2% of the heap and has been doing so far the last 5 (compile time constant) consecutive garbage collections, then a java.lang.OutOfMemoryError is thrown. This exception is typically thrown because the amount of live data barely fits into the Java heap having little free space for new allocations. Action: Increase the heap size. The java.lang.OutOfMemoryError exception for GC Overhead limit exceeded can be turned off with the command line flag -XX:-UseGCOverheadLimit.

2.1.2 Optional flags

The JVM property "memoryDumpOnThreshold" can be set to "true" to enable the creation of memory dumps when reaching the memory threshold. The default value for this property is "false" (so, memory dumps not enabled). You can add this properties on JAVA_AXIONAL_FLAGS property:


2.2 Working with Certificates and SSL

Installation of the Application Server generates a digital certificate in JSSE (Java Secure Socket Extension) format suitable for internal testing. By default, the Application Server stores its certificate information in two files in the domain-dir/config directory:

  • Keystore file,, keystore.jks contains the Application Server’s certificate, including its private key. The keystore file is protected with a password, initially changeit. Change the password using keytool. For more information about keytool, read Using the keytool Utility.
  • Truststore file, cacerts.jks, contains the Application Server’s trusted certificates, including public keys for other entities. For a trusted certificate, the server has confirmed that the public key in the certificate belongs to the certificate’s owner. Trusted certificates generally include those of certification authorities (CAs).

A example to add external certificates to the cacerts.jks file is the Gmail certificates for the mailtool or for the SMTP group configuration.

Download the certificates for the services POP and SMTP. The POP service allows to each user to download the e-mails from the server. The SMTP service allows to send e-mails using the Google account (the protocol must be SMTPS and the port 465).

mkdir /tmp/certs
echo | openssl s_client -connect pop.gmail.com:995 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/certs/gmail_pop.pem
echo | openssl s_client -connect smtp.gmail.com:465 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/certs/gmail_smtp.pem

Then add this certificates to the cacerts file.

keytool -keystore /opt/jdk-9.0.4/lib/security/cacerts -importcert -alias pop.gmail.com -trustcacerts -file /tmp/certs/gmail_pop.pem
keytool -keystore /opt/jdk-9.0.4/lib/security/cacerts -importcert -alias smtp.gmail.com -trustcacerts -file /tmp/certs/gmail_smtp.pem

2.3 Remote Monitoring

The Java virtual machine (Java VM ) has built-in instrumentation that enables you to monitor and manage it using the Java Management Extensions (JMX) technology. These built-in management utilities are often referred to as out-of-the-box management tools for the Java VM. You can also monitor any appropriately instrumented applications using the JMX API.

Monitor the Java VM with a tool that complies to the JMX specification, such as JConsole.

Option Description Default
JAVA_JMX_PORT In the property above, portNum is the port number through which you want to enable JMX RMI connections. Be sure to specify an unused port number 8004

3 Shell utilities

The server provides some shell utilities to obtain information about the system:

  • bin/jps.sh:
  • bin/jstack.sh: prints the current server stacktrace.
  • bin/jvmtop.sh: prints the current CPU load information and the 10 threads with more of CPU.
  • bin/jmap.sh: prints shared object memory maps or heap memory details of a given process or core file or a remote debug server. Generates a file called heapdump.hprof.
  • bin/serverconsole.sh: interactive console that allow get system information.