Friday, December 11, 2015

Java Web Services



Web services - in my simplistic view, these are the software components exposed over web (HTTP) as a service so various other programs or software modules can be able to interact. For easier understanding purpose, it is similar to how a web application deployed on an application server exposes its functions through a UI that a client program like internet browsers can access and display it. Web service even though communicate over HTTP, the exchange of information happens in an XML document with certain rules - called as SOAP (Simple Object Access Protocol)

Java provides an API to develop these components. This is called JAX-WS (Java API for XML Web Services).
And these can be implemented in 2 ways - RPC (remote procedure call) and in a message oriented i.e. in a document style

As this API makes it so simple, we just need below components to develop a simple webservice using JAX-WS

Lets see an RPC style implementation

1. Need a remote i.e. endpoint interface class
2. A remote implementation class
3. A remote publisher class
4. And a client

Below is the self explainable simple code logic

----------------
package com.myWSPackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style = Style.RPC)
public interface IamJustAnInterface{
@WebMethod String implementMe(String name);
}
----------------
package com.myWSPackage;
import javax.jws.WebService;

@WebService(endpointInterface = "com.myWSPackage.IamJustAnInterface")
public class IamAnImplementer implements IamJustAnInterface{
@Override
public String implementMe(String name) {
try{Thread.sleep(10000);}catch(Exception e){}
return "Hi There - at your service : " + name;
}
}
-------------------
package com.myWSPackage;
import javax.xml.ws.Endpoint;

public class IamAPublisher{

public static void main(String[] args) {
  Endpoint.publish("http://localhost:7777/ws/hi", new IamAnImplementer());
    }
}
---------------
package com.myWSPackage;
import java.net.URL;
import javax.xml.namespace.QName;
import javax.xml.ws.Service;

public class WSClient{
  public static void main(String[] args) throws Exception {
  URL url = new URL("http://localhost:7777/ws/hi?wsdl");
    QName qname = new QName("http://myWSPackage.com/", "IamAnImplementerService");
    Service service = Service.create(url, qname);
    IamJustAnInterface ifi = service.getPort(IamJustAnInterface.class);
    System.out.println(ifi.implementMe("Buddy"));
    }
}
---------------------------------------------------

what happens on the client:
I have intentionally put a sleep in the service interface implementation class to capture the stacks

    SocketNativeIO.readBytesPinned(FileDescriptor, byte[], int, int, int)
    SocketNativeIO.socketRead(FileDescriptor, byte[], int, int, int) line: 32
    SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int)
    SocketInputStream.read(byte[], int, int) line: 129
    BufferedInputStream.fill() line: 218
    BufferedInputStream.read1(byte[], int, int) line: 258
    BufferedInputStream.read(byte[], int, int) line: 317
    HttpClient.parseHTTPHeader(MessageHeader, ProgressSource, HttpURLConnection) line: 690
    HttpClient.parseHTTP(MessageHeader, ProgressSource, HttpURLConnection) line: 633
    HttpURLConnection.getInputStream() line: 1195
    HttpURLConnection.getResponseCode() line: 379
    HttpClientTransport.readResponseCodeAndMessage() line: 198
    HttpTransportPipe.process(Packet) line: 151
    HttpTransportPipe.processRequest(Packet) line: 83
    DeferredTransportPipe.processRequest(Packet) line: 78
    Fiber.__doRun(Tube) line: 587
    Fiber._doRun(Tube) line: 546
    Fiber.doRun(Tube) line: 531
    Fiber.runSync(Tube, Packet) line: 428
    Stub.process(Packet, RequestContext, ResponseContextReceiver) line: 211
    SEIStub.doProcess(Packet, RequestContext, ResponseContextReceiver) line: 124
    SyncMethodHandler.invoke(Object, Object[], RequestContext, ResponseContextReceiver) line: 98
    SyncMethodHandler.invoke(Object, Object[]) line: 78
    SEIStub.invoke(Object, Method, Object[]) line: 107 ----> proxy and stub creation has been taken care by JDK
    $Proxy19.implementMe(String) ---------> is the remote call to the webservice's method
    WSClient.main(String[]) line: 15 ---------> is our client main method


what happens on the server side


    Thread.sleep(long) ------> just sleeps for 10 sec before it sends out the response
    IamAnImplementer.implementMe(String) line: 11 ---> call to the interface method which was exposed as a service
    NativeMethodAccessorImpl.invoke0(Method, Object, Object[])
    NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
    DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
    Method.invoke(Object, Object[]) line: 597
    InstanceResolver$1.invoke(Packet, Method, Object[]) line: 235
    InvokerTube$2.invoke(Packet, Method, Object[]) line: 135
    EndpointMethodHandler.invoke(Packet) line: 246
    SEIInvokerTube.processRequest(Packet) line: 82
    Fiber.__doRun(Tube) line: 587
    Fiber._doRun(Tube) line: 546
    Fiber.doRun(Tube) line: 531
    Fiber.runSync(Tube, Packet) line: 428
    WSEndpointImpl$2.process(Packet, WebServiceContextDelegate, TransportBackChannel) line: 232
    HttpAdapter$HttpToolkit.handle(WSHTTPConnection) line: 460
    HttpAdapter.handle(WSHTTPConnection) line: 233
    WSHttpHandler.handleExchange(HttpExchange) line: 95
    WSHttpHandler.handle(HttpExchange) line: 80
    Filter$Chain.doFilter(HttpExchange) line: 65
    AuthFilter.doFilter(HttpExchange, Filter$Chain) line: 65
    Filter$Chain.doFilter(HttpExchange) line: 68
    ServerImpl$Exchange$LinkHandler.handle(HttpExchange) line: 557
    Filter$Chain.doFilter(HttpExchange) line: 65
    ServerImpl$Exchange.run() line: 529
    ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
    ThreadPoolExecutor$Worker.run() line: 908
    Thread.run() line: 662 ----> the publisher start a thread starts


The document style implementation is all the same way as above except the style declared in the remote
interface class will change to DOCUMENT.

The WSDL will be different for each of these implementations although there seems to be no change in the execution path i.e. stack traces shown above.

In Java EE7, there is support to implement RESTful webservices through the API called JAX-RS.
These are best suited when there is no need for state maintenance, can rely on underlying server caching mechanism and the content will not change dynamically and for light weight message exchanges like handsets, portable communication devices etc,. The RESTful services do not require XML messages or WSDL based API implementations.. They depend/implement the REST verbs like PUT/GET/POST/DELETE.. the implementation is very simple - a root reosource class annotated with the @PATH tells where the implemented java class is located and its methods annotated with the verbs like @GET, @Producer etc., tells which type of request handling will be done, what kind of text will be produced and the output etc., the servlet mapping defined the application's web.xml will tell the resource path and the mapped classes ro invoke.






Wednesday, November 25, 2015

Java String, StringBuilder and StringBuffer


What is so different between String, StringBuffer, StringBuilder ?

Strings are simple, constant size and represents a series of characters.
Since they are constants, strings can not be changed and you can simply exchange them.
StringBuilders make them a bit flexible and changeable. While StringBuilder and StringBuffer provides some similar features, StringBuffer is better when it is multi-threaded usage as the methods are synchronized.

A simple example:

public class StringAndStringBuilder {
    public static void changeString(StringBuilder sb){
        sb.delete(0, sb.length());
        sb.append("changed");
    }
public static void changeString(String s){
s="changed";

    }


    public static void main(String[] args) {
        StringBuilder sb=new StringBuilder("nothing");
        changeString(sb);
        System.out.println("value after change via stringbuilder "+ sb);
String s = new String("nothing");
changeString(s);
System.out.println("value after change via string "+ s);

    }
}
output:
value after change via stringbuilder changed
value after change via string nothing

Java Synchronization



Lets see how synchronization works in Java. Below is a sample program which has three parts
- TestSynchronization is a the main class
- TestThread is a private class extends Thread.
- IamSynchronized is one more private class which has synchronized code logic. one part is just a synchronous block and the other is a synchronous method.


public class TestSynchronization {
   public static void main(String args[]) {

      IamSynchronized IS = new IamSynchronized();
      TestThread T1 = new TestThread( "Thread - 1 ", IS );
      TestThread T2 = new TestThread( "Thread - 2 ", IS );
try{Thread.sleep(60000);}catch(Exception e){}
      T1.start();
      T2.start();
   }
}

class TestThread extends Thread {
   private Thread t;
   private String threadName;
   IamSynchronized IS ;
   TestThread(String name, IamSynchronized is){
       threadName = name;
       IS = is;
   }
   public void run() {
     IS.justIterate();
System.out.println("calling sync method - Thread: "+threadName);
IS.syncMethod();
     System.out.println("Thread " +threadName + " done");
   }

   public void start ()
   {
      System.out.println("Starting " +  threadName );
      if (t == null)
      { t = new Thread (this, threadName);
         t.start ();
      }
   }

}

class IamSynchronized {
   public void justIterate(){
    synchronized(this){
try {
         for(int i = 5; i > 0; i--) {
            System.out.println("Iteration --   "  + i );
Thread.sleep(1000);
         }} catch (Exception e) {    System.out.println("Interrupted"+e);  }
}
   }
   public synchronized void syncMethod(){
    {
try {
         for(int i = 5; i > 0; i--) {
            System.out.println("Iteration --   "  + i );
Thread.sleep(1000);
         }
     } catch (Exception e) {
         System.out.println("Interrupted"+e);
     }
   }
}
}

Lets see how the locking works and how the control flow happens when 2 parallel threads trying to execute the same logic.

Starting Thread - 1
Starting Thread - 2
I am in the non synchronous part of justIterate method - Thread Thread - 1
I am Thread Thread - 1  in sync block Iteration --   5
I am in the non synchronous part of justIterate method - Thread Thread - 2        -- THREAD 2 IS BLOCKED BY THREAD1
I am Thread Thread - 1  in sync block Iteration --   4
I am Thread Thread - 1  in sync block Iteration --   3
I am Thread Thread - 1  in sync block Iteration --   2
I am Thread Thread - 1  in sync block Iteration --   1
I am Thread Thread - 2  in sync block Iteration --   5
calling sync method - Thread: Thread - 1  -- THREAD 1 IS BLOCKED BY THREAD2
I am Thread Thread - 2  in sync block Iteration --   4
I am Thread Thread - 2  in sync block Iteration --   3
I am Thread Thread - 2  in sync block Iteration --   2
I am Thread Thread - 2  in sync block Iteration --   1
calling sync method - Thread: Thread - 2  -- THREAD 2 IS AGAIN BLOCKED BY THREAD1 BUT IN SYNC MTHOD
I am Thread Thread - 1  in sync method Iteration --   10
I am Thread Thread - 1  in sync method Iteration --   9
I am Thread Thread - 1  in sync method Iteration --   8
I am Thread Thread - 1  in sync method Iteration --   7
I am Thread Thread - 1  in sync method Iteration --   6
Thread Thread - 1  done
I am Thread Thread - 2  in sync method Iteration --   10  -- SINCE THREAD1 RELEASES LOCK, THREAD2 CONTINUES
I am Thread Thread - 2  in sync method Iteration --   9
I am Thread Thread - 2  in sync method Iteration --   8
I am Thread Thread - 2  in sync method Iteration --   7
I am Thread Thread - 2  in sync method Iteration --   6
Thread Thread - 2  done


Below stack trace gives an idea on how the locks being handled by the JVM


"Thread - 2 " prio=6 tid=0x000000000b550800 nid=0x2478 waiting for monitor entry [0x000000000d48f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at IamSynchronized.justIterate(TestSynchronization.java:47)
        - waiting to lock <0x00000007d5fbab18> (a IamSynchronized)
        at TestThread.run(TestSynchronization.java:24)
        at java.lang.Thread.run(Thread.java:722)

"Thread - 1 " prio=6 tid=0x000000000b550000 nid=0x18c4 waiting on condition [0x000000000d17f000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at IamSynchronized.justIterate(TestSynchronization.java:49)
        - locked <0x00000007d5fbab18> (a IamSynchronized)
        at TestThread.run(TestSynchronization.java:24)
        at java.lang.Thread.run(Thread.java:722)

--------------------------------------------------

"Thread - 2 " prio=6 tid=0x000000000b550800 nid=0x2478 waiting on condition [0x000000000d48f000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at IamSynchronized.justIterate(TestSynchronization.java:49)
        - locked <0x00000007d5fbab18> (a IamSynchronized)
        at TestThread.run(TestSynchronization.java:24)
        at java.lang.Thread.run(Thread.java:722)

"Thread - 1 " prio=6 tid=0x000000000b550000 nid=0x18c4 waiting for monitor entry [0x000000000d17f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at IamSynchronized.syncMethod(TestSynchronization.java:56)
        - waiting to lock <0x00000007d5fbab18> (a IamSynchronized)
        at TestThread.run(TestSynchronization.java:26)
        at java.lang.Thread.run(Thread.java:722)

--------------------------------------------------

"Thread - 2 " prio=6 tid=0x000000000b550800 nid=0x2478 waiting for monitor entry [0x000000000d48f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at IamSynchronized.syncMethod(TestSynchronization.java:56)
        - waiting to lock <0x00000007d5fbab18> (a IamSynchronized)
        at TestThread.run(TestSynchronization.java:26)
        at java.lang.Thread.run(Thread.java:722)

"Thread - 1 " prio=6 tid=0x000000000b550000 nid=0x18c4 waiting on condition [0x000000000d17f000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at IamSynchronized.syncMethod(TestSynchronization.java:58)
        - locked <0x00000007d5fbab18> (a IamSynchronized)
        at TestThread.run(TestSynchronization.java:26)
        at java.lang.Thread.run(Thread.java:722)

--------------------------------------------------

"Thread - 2 " prio=6 tid=0x000000000b550800 nid=0x2478 waiting on condition [0x000000000d48f000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at IamSynchronized.syncMethod(TestSynchronization.java:58)
        - locked <0x00000007d5fbab18> (a IamSynchronized)
        at TestThread.run(TestSynchronization.java:26)
        at java.lang.Thread.run(Thread.java:722)

Tuesday, October 13, 2015

Eclipse MAT - Analyzing heap dumps


Eclipse Memory Analyzer Tool is one of the best tools to analyze JVM heap dumps and to understand the memory allocations, memory leaks etc., Below listed are kind of pointers to what MAT gives and what they actually mean in analyzing the heap dump

The Overview report is the best one to start. It gives
size of your heap dump - which could be very less than the XMX or in most of the cases a bit larger than the XMX. The first case examples are - OOM thrown not in the heap but other areas like perm space, TLA or may be it just could not allocate a large char array say gt. 2GB while there is still lot of free space or sometimes not able to dump large collection of objects which are pending with finalizer thread.

Classes: number of classes loaded

Objects: number of objects loaded 

Class Loaders: number of class loaders


Unreachable objects histogram: these are normally removed during analysis but can be set not to by using preference 'keep_unreachable_objects'

The overview report also gives pointers on where to look..

Histogram - gives the number of instances per class.
you can obtain the shallow & retained sizes (shallow heap is the mem. occupied by one object of a class. retained heap is the sum of shallow sizes of all the objects of a class)
you can calculate the approx. or precise retained size of a class or package. group the histogram view at package level or a class loader..
you can also explore the top packages or class loaders by going through outgoing references. outgoing references are basically the tree nodes or leaves that a specific object refers to. Incoming references of an object are basically all the links i.e. references that kept the object alive

Dominator tree - is an object graph showing all the dominators list. it is basically showing all the 'dominating' links of an object tree. 

top consumers - it is similar to grouping the histogram view by packages. But nice report to know which packages are the top consumers of the memory. So that we can further explore which classes of the top consuming packages are being instantiated or retaining more space and what are their immediate dominators or gc roots

duplicate classes - gives the list of duplicate classes loaded by different class loaders. If your perm gen space is filling up then probably this view will give good indication on what classes are being loaded and duplicate list.

In addition to above, there are 2 good reports given by MAT 

Leak Suspects:It points out what are the biggest objects occupying the memory. They may or may not be the leaks but worth to begin the investigation with. It tells how many instances and memory consumed by each instance. you can also get the gc root information like which gc root like a thread, class loader etc., have instantiated the objects. (This can be obtained from leak hunter report.) It also gives system & thread overview, top consumers, class histograms.

Top Components: use this if there are no heavy objects found by leak suspects. This report will give detailed analysis for all the objects occupying gt. 1% of heap.


Finalizers: this is one more important feature to see what the finalizers are doing. Finalize methods will be executed to free up the object. sometimes if there a long running code in finalize method or a lock in the finalize method could delay in cleaning up the heap. This could result in large accumulation of objects pending for finalization. in MAT, go to Java Basics -> Finalizer Overivew to view these stats. If Finalizer Overview does not show any data then check the thread which is doing finalization like 'Finalizer thread' in weblogic and check how much space it has retained. If that does not show any significant memory held and the heap dump is not the same size as reported in verbose GC logs just before the dump then live monitoring of class histogram is the option. It could be that there are huge number of objects loaded and not live and waiting to get finalized.

you can also query the heap using OQL, analyze threads to see thread stacks, URLs, thread states etc., java collection usage,



Knowing all the above, A quick way to analyze the heap dump is take a look at the leak suspects after getting a high level idea from overview report. see if there are any large collection of an objects is being loaded and by which class loader. now get the path to gc roots (or merge shortest path option for top instances by retained size) from histogram if not given in the suspects report, to find out who is/are holding these objects in the memory. once we know who is holding, now see what the object contains i.e. the content. sometimes there will be a single object holding large amount of memory like some big xml report generation or there could be large collection of small objects occupying the memory. In the second case see why so many instances rather than the size of each instance.