Friday, December 25, 2015

How to create a heap dump of your Java application

Heap in a JVM, is the place where it keeps all your runtime objects. The JVM create a dedicated space for the heap at the JVM startup, which can be controlled via JVM option -Xms<size> eg: -Xms100m (this will allocate 100MBs for the heap). JVM is capable of increasing and decreasing the size of the heap [1] based on the demand, and JVM has another option which allows to set max size for the heap, -Xmx<size>, eg: -Xmx6g (this allows the heap to grow up to 6GBs)

JVM automatically perform Garbage Collection (GC), when it detects its about to reach the heap size limits. But the GC can only clean the objects which are eligible for GC. If the JVM can't allocate required memory even after GC, JVM will crash with "Exception in thread "main" java.lang.OutOfMemoryError: Java heap space"

If your Java application in production crashes due to some issue like this, you cant just ignore the incident, and restart your application. You have to analyze the what cause the JVM crash, and take the necessary actions to avoid it happening again. This is where the JVM heap dump comes in to the play.

JVM heap dumps are by default disabled, you have to enable heap dumps explicitly by providing following JVM option, -XX:+HeapDumpOnOutOfMemoryError

The below sample code, tries to create a multiple, large arrays of chars, and keep the references in list. Which cause those large arrays ineligible for garbage collection.

package com.test;

import java.util.ArrayList;
import java.util.List;

public class TestClass {
    public static void main(String[] args) {
        List<Object> list = new ArrayList<Object>();
        for (int i = 0; i < 1000; i++) {
            list.add(new char[1000000]);
        }
    }
}

If you run the above code with following command lines,

1. java -XX:+HeapDumpOnOutOfMemoryError -Xms10m -Xmx3g com.test.TestClass

Result: Program runs and exit without any error. The heap size starts from 10MB and then grows as needed. Above needs memory less than 3GB. So, it completes without any error.

2. java -XX:+HeapDumpOnOutOfMemoryError -Xms10m -Xmx1g com.test.TestClass

Result: JVM crashes with OOM.

If we change the above code a bit to remove the char array from the list, after adding to the list. what would be the result


package com.test;

import java.util.ArrayList;
import java.util.List;

public class TestClass {
    public static void main(String[] args) {
        List<Object> list = new ArrayList<Object>();
        for (int i = 0; i < 1000; i++) {
            list.add(new char[1000000]);
            list.remove(0);
        }
    }
}

3. java -XX:+HeapDumpOnOutOfMemoryError -Xms10m -Xmx10m com.test.TestClass

Result: This code runs without any issue even with a heap of 10MBs.

NOTE:
1. There is no impact to your application if you enable the heap dump in the JVM. So, it is better to always enable -XX:+HeapDumpOnOutOfMemoryError in your applications

2. You can create a heap dump of a running Java application with the use of jmap. jmap come with the JDK. Creating a heap dump of a running application cause the application to halt everything for a while. So, not recommended to use in production system. (unless there is a extreme situation)
eg: jmap -dump:format=b,file=test-dump.hprof [PID]

3. Above sample codes are just for understanding the concept. 

[1] https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html


Edit:

Following are few other important flags that could be useful in generating heap dumps;

-XX:HeapDumpPath=/tmp/heaps
-XX:OnOutOfMemoryError="kill -9 %p" : with this you can execute command at the JVM exit
-XX:+ExitOnOutOfMemoryError : When you enable this option, the JVM exits on the first occurrence of an out-of-memory error. It can be used if you prefer restarting an instance of the JVM rather than handling out of memory errors [2].
-XX:+CrashOnOutOfMemoryError : CrashOnOutOfMemoryError - If this option is enabled, when an out-of-memory error occurs, the JVM crashes and produces text and binary crash files (if core files are enabled) [2].

[2] http://www.oracle.com/technetwork/java/javase/8u92-relnotes-2949471.html

Wednesday, December 23, 2015

The core of the next-generation WSO2 Carbon platform : WSO2 Carbon Kernel 5.0.0

A whole new revamp of the heart of all WSO2 products : WSO2 Carbon Kernel 5.0.0, was released 21 Dec 2015.

Previous versions of the WSO2 Carbon Kernel, (1.x.x to 4.x.x) had a much similar architecture and was tightly coupled with relatively old technologies (axiom, axis2, SOAP, etc.). Which is the same reason, which made us to re-think and re-architecture everything from the ground, and to come up with WSO2 Carbon Kernel 5.0.0.

The new Kernel is armed with the latest technologies and patterns. It will provide the key functionality for server developers on top of the underline OSGi runtime.

Key Features
  • Transport Management Framework
  • Logging Framework with Log4j 2.0 as the Backend
  • Carbon Startup Order Resolver
  • Dropins Support for OSGi Ready Bundles
  • Jar to Bundle Conversion Tool
  • Artifact Deployment Engine
  • Pluggable Runtime Support

You can download the product from [1], and find more information on [2].

[1] http://product-dist.wso2.com/products/carbon/5.0.0/wso2carbon-kernel-5.0.0.zip
[2] https://docs.wso2.com/display/Carbon500/WSO2+Carbon+Documentation

Friday, December 18, 2015

Logging with SLF4J

The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks. It allows you to code just depending on a one dependency namely "slf4j-api.jar", and to plug in the desire logging framework at runtime.

It is very simple to use slf4 logging in your application. You just need to create a slf4j logger and invoke its methods.

Following is a sample code,

package com.test;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Main {
    private static final Logger logger = LoggerFactory.getLogger(Main.class);

    public static void main(String[] args) {
        logger.info("Testing 123");
    }
}

You have to add the following dependency in your pom.xml file

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.13</version>
</dependency>

This is the bare minimum configuration you need to enable sl4fj logging. But if you run this code. you will get a warning similar to the below.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

This is because, it can't find a binding in the class path, by default, if it can't find a binding in the class path, it will bind to no-op logger implementation.

Using java.util.logging

If you want to use the binding for java.util.logging in your code, you only need to add the following dependency in to your pom.file.

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-jdk14</artifactId>
    <version>1.7.13</version>
</dependency>

This will output the following,

INFO: Testing 123


Using Log4j

If you want to use the binding for log4j version 1.2 in your code, you only need to add the following dependency in to your pom.file.

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.13</version>
</dependency>

Log4j needs an appender to log. Hence, you have to specify the log4j properties.

Create the file "log4j.properties", in resource directory of your project and add the following into it.

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=DEBUG, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

This will output the following,


0    [main] INFO  com.test.Main  - Testing 123


[1] http://www.slf4j.org/
[2] http://logging.apache.org/log4j/1.2/index.html

WSO2GREG : Upload files

WSO2 Governance registry (WSO2GREG) is a metadata repository. It supports storing, cataloging, indexing, managing and governing your enterprise metadata related to any kind of asset.

Uploading files directly in to the GREG is not recommended. What is recommended is to upload the files in to a file server and use a link to the file as a metadata.

But there may be situations where you really need to keep the files in GREG itself. Let's see how you can do this in GREG.


1. Download the file.rxt file from [1].
2. Create a new artifact type from the WSO2GREG management console. Extensions-> Configure->Artifact Types->Add new Artifact
3. Download the "file" extension from [2]
4. Copy the "file" directory to "[GREG_HOME]/repository/deployment/server/jaggeryapps/publisher/extensions/assets/"

This will add a new item "file" in to the menu and you should be able to upload and download files in WSO2GREG.

If you need to make any association to "files" you upload here, you have to do the following to list the files in the associations view.

Let's assume you want link these files to "soapservice" artifact. Then do the following.

1. Edit the Association types for "soapservice" in [GREG_HOME]/repository/conf/governance.xml file to have the file details
<file>file</file>

Following is a sample configuration for Association type="soapservice", once you add the "file" type


<Association type="soapservice">
<security>policy</security>
<ownedBy>soapservice,restservice,wsdl</ownedBy>
<usedBy>soapservice,restservice,wsdl</usedBy>
<dependancies>soapservice,restservice,wsdl,endpoint</dependancies>
<file>file</file>
</Association>

[1] http://www.mediafire.com/view/dtog4qdrs1v0mw1/file.rxt
[2] http://www.mediafire.com/download/6df8eofni2tqtwr/file.zip


Sunday, December 13, 2015

WSO2GREG : Categorized view of your assests


Let's assume you have five services, namely, Service1, Service2, Service3, Service4 and Service5. If you just create these service in the WSO2GREG, all those services will be displayed as follows,


Sometime it is needed to group the assets based on some criteria. Let's say, Service1 and Service2 belongs to DepartmentA and Service3, Service4, Service5 belongs to DepartmentB.

If we need to have a categorized view based on the department. Follow the below mentioned steps.

1. Add the following filed to the "soapservice" artifact. You edit it via management console. Extensions->Configure->Artifact Types->soapservice->Edit


<field type="options">
  <name label="Category">Category</name>
  <values>
    <value>Department1</value>
    <value>Department2</value>
  </values>
</field>

2. Download the asset.js file in the following location and copy it to the following location [GREG_HOME]/repository/deployment/server/jaggeryapps/publisher/extensions/assets/soapservice (replace the existing asset.js file)

http://www.mediafire.com/view/ka31hd4q5eqt44u/asset.js

3. Restart the server

4. You can now see, a new dropdown got appear in front of the search box.



5. Go to each of those service and edit those service to have its corresponding department in the "Category" field.

6. You can now view and search on the selected category.





Friday, December 11, 2015

WSO2GREG Publisher and Store

New WSO2 Governance registry (WSO2GREG) comes with a brand new two applications

1. Governance Center : Publisher
2. Governance Center : Store

These two will be the main UIs to deal with the assets (assets governance), WSO2 will no longer encourage to use the management console for artifact management. (you can use the management console to setup assets, lifecycles, users, etc. but not for artifact management)

Governance Center : Publisher



Governance Center : Store