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/axional $ 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
... <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
2 Adding services in systemd
Adding services in systemd daemons make it is easier to supervise and control processes and parallelized job execution
systemctl command provides the administrator with more detailed error messages including runtime and start-up errors.
Process attributes such as function and ownership are much easier to ascertain. For example, under Systemd, sub-processes, once spawned, become 'children' and are organized under the appropriate 'parent' group to show inheritance.
The user axional is needed to put the content of services and manage the start and stop of them.
The studio server is installed on /home/axional/studio.
The microservices server is installed on /home/axional/microservices.
Edit the new file /etc/systemd/system/ax-studio.service and add the content asuming the path of studio server is on /home/axional/studio:
[Unit] Description=Deister Axional Studio Service After=network.target Wants=ax-microservices.service [Service] User=axional Type=forking KillMode=control-group ExecStart=/bin/sh -a -c 'cd /home/axional/studio && bin/studio.sh --start' #ExecStop=/bin/kill -SIGTERM $MAINPID ExecStop=/bin/sh -a -c 'cd /home/axional/studio && bin/studio.sh --stop' Restart=on-failure RestartSec=30s [Install] WantedBy=multi-user.target
- Wants: indicates that is required the axional studio microservices to start the service. If the microservices is not in the same server you need to comment this line. This ensure that the microservices will be started when the studio starts.
- ExecStop: uses the command stop asumes that the port to stop is configured in the config.xml If not you must use kill.
Enable the service:
systemctl enable ax-studio
When the axional studio microservices is in the same server you need to add this service in systemd. Edit the new file /etc/systemd/system/ax-microservices.service and add the content asuming the path of the installation is /home/axional/microservices:
[Unit] Description=Deister Axional Microservices Service After=network.target [Service] User=axional Type=forking KillMode=control-group ExecStart=/bin/sh -a -c 'cd /home/axional/microservices && bin/services.sh --start' ExecStop=/bin/kill -SIGTERM $MAINPID Restart=on-failure RestartSec=30s [Install] WantedBy=multi-user.target
Enable the service:
systemctl enable ax-microservices
To start the services you can execute:
systemctl start ax-studio
and this commands checks that microservices is started and starts it if not.
To stop the service you can execute
systemctl stop ax-studio
3 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.
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
3.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
3.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:
3.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).
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
3.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.
|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|
4 Shell utilities
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.