Software Architecture – Hexagonal Architecture Pattern

software_architecture_patterns

                     In this article we will see “Hexagonal Architectural Pattern” also known as “Ports and Adapters” pattern. As developers so far we have created applications with tiered architecture styles like MVC (Model View Controller). With this architectural styles, up to certain extent we were able to decouple the domain logic with other functionalities. At times the domain logic use to leak into UI or other functionalities. As the core logic is getting leaked into other layers , the impact of the code change will have ripple effect on other modules. To avoid this we can go with “Ports and Adapters” architecture style.

                      The “Ports and Adapters” style will have domain logic as Core and the Adapters will have the application logic specific  to translate an interface from outside request  into a compatible one. The core and the adapters sits as inner layer. The ports sits on outer layer to interact with the external services. The below diagram depicts the above said architectural style.

hexagonal-architecture

                        The advantages of this style is the core logic abstracted from the out side world. The code is decoupled via the adapters. We can add or remove the new functionalities easily. We can perform testing of core logic and the adapters in isolation mode.

                      In the coming article we will see what is micro services architectural style? and what are the driving factors behind it? Till then Stay Tune!!!

Advertisements
Tagged with: ,
Posted in Design Patterns

Gatling – Integration with Maven

gatling-logo

                                               In this article we will see how to use Gatling with Maven. This approach enables us to integrate Gatling as part of continuous integration. Along with that we will see how to externalize properties used in simulation script and the dynamic data feeding using Gatling feeders. Let us see the above said features in action.

As a first step create a maven project and add the below Gatling dependencies.

Now, we will externalize the baseURL property used in our simulation. For this add the application.properties file under src/test/resources and use ConfigFactory to get access to the properties. The sample simulation is given below.

Now, we will see how to add dynamic data used as part of simulation. For this I am using Gatling’s CSVFeeder. You can get more info on Gatling’s feeders http://gatling.io/docs/2.2.3/session/feeder.html. Add the feeder file under src/test/resources/data. The sample simulation using csv feeder is given below.

Run mvn gatling:execute to execute Gatling project which will run the simulations. The entire project used for this article is available on GitHub.

Gatling Maven Demo

Tagged with: , ,
Posted in Testing

Gatling – Light weight load testing tool

gatling-logo

                                   Gatling is a light weight stress testing tool backed by Scala, Akka and Netty. It  works asynchronously if the under lying HTTP request is non blocking. It uses messages for virtual user simulation than thread per virtual user. Because of this it consumes lesser system resources to run load test. In this article let us see a REST endpoint load testing by following the below steps.

Step 1: Download the Gatling bundle from http://gatling.io/#/resources/download . The folder structure of GATLING_HOME is explained below.

gatling_folder_structure

Step 2: Set GATLING_HOME and JAVA_HOME environment variables and write a sample simulation using Scala. As a java developer you no need to have strong Scala knowledge to write Gatling simulations with Scala. We need to have very basic knowledge. A simulation is given below to test a REST end point.

                     In the above simulation we are ramping up the 1000 users in 10 seconds. Once the simulation script is ready, go to the bin folder and launch the gatling.bat/gatling.sh. The script will run the simulation available under “simulations” folder and generates the reports under results folder.

The sample report is given below.

gatling_performance_stats

In the coming article we will see how to use Gatling maven integration and additional features like feeders, externalizing the properties etc… Till then, Stay Tune!!!

Tagged with: , ,
Posted in Testing

Byteman – Byte code manipulation tool for Logging, Testing and Fault Injection

Byteman

Byteman is a byte code manipulation tool for fault injection, testing and tracing. The Byteman agent allows to inject the rules into the existing java application with out changing the source code. You can inject the rules during the JVM startup time or into running application with out build and redeploy. We can inject the rules for custom java classes, private methods and the JRE libraries as well. Below are the Byteman use cases.

  • Add logging statements for the legacy application
  • Inject fault scenarios to the application via Junit or TestNG unit test cases

Now, we will see simple java application for which we will add debug statements via Byteman.

Let us write a simple Java application.


package org.smarttechie;

/**
* Class will demonstrate the Byteman
* @author Siva
*
*/
public class BytemanDemonstration {
public static void main(String[] args) {
    System.out.println("With this class we are demonstrating the byteman");
 }
}

Download the latest Byteman distribution.

Write Byteman script to inject the debug statements for the above class.


RULE trace main entry
CLASS BytemanDemonstration
METHOD main
AT ENTRY
IF true
DO traceln("entering into main method")
ENDRULE

RULE trace main exit
CLASS BytemanDemonstration
METHOD main
AT EXIT
IF true
DO traceln("exiting the main method")
ENDRULE

Launch the JVM by passing the Byteman agent and the script file path.

 java -javaagent:${Byteman_Home}\lib\byteman.jar=script:${SCRIPT_FILE_PATH}\logrules.btm <class_name>

After launching the JVM, you will able to see the log messages coming from the script file.


entering into main method
With this class we are demonstrating the byteman
exiting the main method

For further exploration, follow the below links.

https://developer.jboss.org/wiki/ABytemanTutorial#top

https://developer.jboss.org/wiki/BMUnitUsingBytemanWithJUnitOrTestNGFromMavenAndAnt#top

Tagged with: ,
Posted in Java

Memory Analysis – How to obtain Java Heap Dump?

Java Heap Dump

In this article we will see how to obtain the Java Heap Dump to troubleshoot the memory issues like memory leak and high usage of memory. There are different options available to obtain the Heap Dump. The options will vary based on the JVM vendors. In this article I used Oracle JDK8.

Automatically generate the Heap Dump when application throws “OutOfMemoryError”

In this approach, we have to pass the below JVM arguments to get the Heap Dump when application throws “OutOfMemoryError“. The JVM generates the Heap Dump file in the specified file path.

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to this heap dump file>

If you have not specified the HeapDumpPath, then the JVM generates the file where the JAVA process is running. The name of the dump file will be like java_pid.hprof.

Some times we might require Heap Dump on demand basis. For example, during the peak load application may become slower and the memory consumption might be more. To troubleshoot the memory consumption, we require Heap Dump.

Manually Generating a Heap Dump

From JDK6, we are having jmap tool to generate the Heap Dump on demand basis. jmap will dump the Java heap in binary HPROF format to a specified file. The instruction is given below.

jmap -dump:format=b,file=<file_name> <pid>
For example, jmap -dump:format=b,file=heap_dump.hprof 4988

In the above example, the 4988 is the java process id to get the heap dump. We can obtain the process id by using jps(Java Virtual Machine Process Status Tool)

There is another GUI utility called jconsole. jconsole can connect to local java process or remote java process. By using MBeans we can get the heap dump.

We can use jvisualvm GUI tool to connect to local or remote JAVA processes. Through jvisualvm also we can generate the heap dump.

All the above said tools are part of JDK. Set the JAVA_HOME and PATH environment variables to access the tools.

In the next article we will see the tools to analyse the heap dumps to detect the memory issues. Till then, stay tune!!! 

 

Tagged with: , , ,
Posted in Java, Performance

Enabling and Analysing the Garbage Collection log

Java

In the last article we discussed on the Garbage Collection process. In this article we will learn how to enable the garbage collection log and see what insights we will get from the GC log to tune the JVM.

As a developer every one will get a question on enabling the GC log on production servers. Is it advisable to enable GC log on production server? Yes, it is recommended to enable the GC log on production servers. The overhead by enabling the GC log on JVM is minimal. As per Standard Performance Evaluation Corporation (SPEC)  the world record high performance Java Enterprise production servers are running with GC log enabled. We have to pass the JVM arguments to enable the GC log. Below are the options given for JDK8 Oracle HotSpot JVM.

Note: Set the heap size as low to get the GC log for exercise.

-XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCDateStamps -Xloggc:gclog.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=2000k

Let us understand the purpose of each option. These options may vary based on the OS/JVM vendor/JAVA version.

DisableExplicitGC: By default this option is disabled. Some times developers might have invoked garbage collection pragmatically by calling System.gc() or Runtime.getRuntime().gc(). This is not advisable. Hence in production systems we enable this option. So that the pragmatic invocation of garbage collection is disabled.

PrintGCDetails: By default this option is disabled. If we enable this option, JVM prints more details at each garbage collection.

PrintGCApplicationStoppedTime: By default this option is disabled. If we enable, it prints the information on application pause during the garbage collection.

PrintGCApplicationConcurrentTime: By default this option is disabled. If we enable, it prints the information on application running time during the GC.

PrintGCDateStamps: By default this option is disabled. If we enable, it prints the date and time details at each GC.

loggc: This is a string option. We have have to pass the gc log file name. In this file we will get all the GC log information.

UseGCLogFileRotation: This option indicates the JVM to rotate the log file, if the file size reaches to the specified size.

NumberOfGCLogFiles: The default value is 1. This sets the number of files to use when rotating logs.

GCLogFileSize: The default value is 8KB. The size of the log file at which point the log will be rotated.

By setting the above options, we are ready to get the GC log. To tune the JVM it is better to enable these options during the load test and take the GC log on different loads for analysis. From the GC log we have to observe the below parameters.

  1. How often the Young GC and Full GC is occurring? There should be several minutes time gap between the GC events. If the Young GC is happening more often, then we might need to look at the allocated Young Gen space. If the Full GC is happening more often, then we need to look at the allocated heap size. 
  2. How much time each GC event is taking to complete? Ideally the Young GC will take couple of milli seconds and the Full GC will take couple of milliseconds to seconds. At any circumstance, if the GC is taking several seconds to minutes, then we have to look at the Heap size tuning. If the GC thread takes more time to complete the garbage collection, the application threads will be in wait state(GC is stop the world event). This impacts the user experience.

I have created a sample application to generate the enough GC log. Now, we will understand the same here.

gclog analysis

There are some GC log viewers. Here is the one of the GC log analyzer(http://gceasy.io/). If you upload the GC log, it will provide detailed analysis with the charts to understand. Based on the GC analysis, we can tune the heap size, Young gen space and Tenured space. In the coming article will discuss the different performance related JVM options. Till then Stay Tuned!!!.

Tagged with: , , , , ,
Posted in Java, Performance

Understanding The Java Memory Model and The Garbage Collection

Java

In this article we will try to understand the Java memory model and how the garbage collection works. In this article I have used JDK8 Oracle Hot Spot 64 bit JVM. First let me depict the different memory areas available for the Java process.

JVM Memory Allocations

Once we launch the JVM, the operating system allocates the memory for the process. Here the JVM itself is a process and the memory allocation to that includes the Heap, Meta Space, JIT code cache, thread stacks and the shared libraries. We call it as native memory. The “Native Memory”  is the memory provided to the process by the operating system. How much memory the operating system allocates to the Java process depends on the operating system, processor and the JRE. Let me explain the different memory blocks available for JVM.

Heap Memory: JVM uses this memory to store the objects. This memory in turn split into two different areas called “Young Generation Space” and “Tenured Space“.

Young Generation: The Young Generation or the New Space is divided into two portions called “Eden Space” and “Survivor Space“.

Eden Space:When we create an object, the memory will be allocated from Eden Space.

Survivor Space: This contains the objects that have been survived from the Young garbage collection or Minor Garbage Collection. We have two equally divided survivor spaces called S0 and S1.

Tenured Space: The objects which reach to max tenured threshold during the minor GC or young GC, will be moved to “Tenured Space” or “Old Generation Space“.

When we discuss the garbage collection process we will come to know how the above said memory locations will be used.

Meta Space: This memory is out of heap memory and part of the native memory. As per the document by default the meta space doesn’t have upper limit. In earlier versions of Java we call this as “Perm Gen Space“. This space is used to store the class definitions loaded by the class loaders. This is designed to grow to avoid the Out Of Memory Errors.  But, if it grows more than the available physical memory, then the operating system will use virtual memory. This will have adverse effect on the application performance as swapping the data from virtual memory to physical memory and vice versa is costlier operation. We have JVM options to limit the Meta Space used by JVM. In that case, we may get out of memory errors.

Code Cache: JVM has interpreter to interpret the byte code and converts the same into hardware dependent machine code. As part of JVM optimization the Just In Time(JIT) compiler has been introduced. The frequently accessed code blocks will be compiled to native code by JIT and stored it in code cache . The JIT compiled code will not be interpreted.

Now let us discuss the garbage collection process. The JVM uses a separate demon thread to do garbage collection. As we said above when the application creates the object the JVM try to get the  required memory from the eden space. The JVM performs GC as minor GC and major GC. Let us understand the minor GC.

Minor Garbage Collection

Initially the survivor space and the tenured space is empty. When the JVM is not able to get the memory from the eden space it initiates the minor GC. During the minor GC, the objects which are not reachable are marked to garbage collect. JVM selects one of the survivor space as “To Space”. It might be S0/S1. Let us say JVM selected S0 as “To Space”. JVM copies the reachable objects to “To Space” that is S0 and increments the reachable objects age by 1. The objects which are not fit into survivor space will be moved to tenured space. This process is called “premature promotion”. For the representational purpose I have made  the “To Space” as bigger than the allocated space. Remember the survivor space won’t grow.

Minor Garbage Collection

In the above diagram the objects marked with RED color indicates non reachable. All the reachable objects are GC roots. The garbage collector won’t remove the GC roots. The garbage collector removes the non reachable objects and empties the eden space.

For the second minor GC, the garbage collector marks the non reachable objects from “eden space” and the “To survivor space(S0)” and copies the GC roots to other survivor space S1 and the reachable objects age will be incremented.

Minor Garbage Collection

In the above diagram, the objects marked with RED are eligible to GC and the other objects will be copied from eden and the from survivor space to other survivor space S1 with the objects age incremental.

Minor Garbage Collection

The above process repeats for each minor GC. When objects reached to max age threshold then those objects are copied to tenured space.

Minor Garbage Collection

There is a JVM level option called “MaxTenuringThreshold” to specify the object age threshold to promote the object to tenured space. By default the value is 15.

So it is clear that the minor GC reclaims the memory from “Young Generation Space“. The minor GC is “Stop the world” process. Some times the application pause is negligible. The minor GC will be performed with single thread or multi thread based on the GC collector applied.

If the minor GC triggers several times eventually the “Tenured Space” will be filled up and requires to be garbage collected. During this time the JVM triggers “major GC” event. Some times we call this as full GC. But, as part of full GC the JVM reclaims the memory from “Meta Space”. If there are no objects in the heap, then the loaded classes will be removed from the meta space.

Now let us see what are the possibilities that the JVM triggers the major GC.

  • If the developer calls System.gc() or Runtime.getRunTime().gc() suggests the JVM to initiate the GC.
  • If JVM decides there is no enough tenured space, then it triggers major GC
  • Minor GC may trigger major GC. During the minor GC if JVM is not able to reclaim enough memory from eden or survivor space.
  • If we set “MaxMetaspaceSize” option for JVM and there is no enough space to load new classes, then JVM triggers major GC.

In the coming articles we will analyze the garbage collection log to get insights to tune the JVM for better performance. Till then stay tune!!!

Tagged with: , , ,
Posted in Java, Performance
DZone

DZone MVB

Java Code Geeks
Java Code Geeks