Axional Studio provides the shells to start and stop the application and more shells utilities to help to obtain system information.
Use the provided shell script start.sh to start and studio.sh to stop the application
To start the service use the option:
to starts the service setting the JVM parameters for memory.
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
... <stop> <port>8777</port> <pass>Password2Stop</pass> </stop> ...
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
The main shell script tool (bin/studio.sh) creates a file (bin/.studio.env) with the default values for Java modifiers if it does not exist. So settings like memory, product compatibility options, etc can be adjusted without the need of changing the provided script.
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.
|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:
For example, in a host with more than 12 GB of RAM, the following line in bin/.studio.env
should be changed to
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
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
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
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:
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).
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
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.
|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|
The server provides some shell utilities to obtain information about the system:
- 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.