Archive for the ‘Glassfish’ Category

Tuning suspended AsyncResponse and Thread-pools in Glassfish 4

Posted: July 26, 2013 in Glassfish, Java
0

I am experimenting with Glassfish 4 to prepare in order to move some application from J2EE6 to J2EE7. Glassfish 4 works with J2EE 7 and introduces some new concepts. The one which we are investigating today is the use of @Asynchronous and @Suspended in REST resources.

The use of the asynchronous annotations is pretty well specified for beans but there are some pitfalls when it comes to REST services. Let’s go through an example and check the behavior of a REST service with asynchronous methods as we go.

The use case is the following. We define a Resource and one Bean. The resource is a typical REST-resource with only one GET-method. The bean is a normal, stateless session bean which performs a long running task. This bean is pretty straightforward. We do not annotate the methods of the bean as asynchronous.

@Stateless
public class LongSession {
   public String doLongTask() {
       try {
           // do a long task
           Thread.sleep(10*1000);
       } catch (InterruptedException ex) {
           // ignore
       }
       
       return "done";
   }
}

The first resource we build is pretty simple. We create an @Stateless resource and inject a @Suspended AsyncResponse. AsyncResponse takes care of the asynchronous response when the results become available.

@Path("as")
@Stateless
public class AsResource {

    @EJB
    private LongSession longSession;
    
    @GET
    @Produces(MediaType.TEXT_HTML)
    @Asynchronous
    public void getXml(@Suspended AsyncResponse resp) {
        System.out.println("do a long task in thread: " + Thread.currentThread().getName());
        String result = this.longSession.doLongTask();
        Response r = Response.ok("this is the " + result).build();
        resp.resume(r);
    }
 
}

When we open the browser and point to the URL of this resource we will see that the request is blocked for 10 seconds! But that is nothing new. Now, the problem is that we want to know how many threads are available to serve these requests. We are using a stateless bean, so we use the thread-pool of the ejb-container. This has some implications. When we use the http-thread-pool we will basically the same behavior, but we are not interested in the request thread. I want to scale out the ejb-pool. Adding beans to the pool is apparently not enough.

When you press F5 continuously in the browser, you will see something like “INFO: do a long task in thread: __ejb-thread-pool1” in the log. This number counts up and exceeds the threads in the http-thread-pool thanks to the AsyncResponse and @Suspended. But you will see (in a freshly installed domain) that the thread-pool does not exceed the limit of 16 even though you have max. 64 beans in your pool. We need to finetune the thread-pool of the ejb-container. But, you won’t find any properties in the administrator console. You need to add them yourself. Open the domain.xml of your domain and add the following lines: 

     <ejb-container max-pool-size="64" steady-pool-size="7">
        <property name="thread-core-pool-size" value="10"></property>
        <property name="thread-max-pool-size" value="20"></property>
        <property name="thread-queue-capacity" value="25"></property>
        <ejb-timer-service></ejb-timer-service>
      </ejb-container>

Now, rerun your application. You will see that the thread-pool goes up to 10 when you press F5 in the browser without holding it down. It seems to stagnate on 10 although you kinda specified a max-pool-size of 20. When you continuously press F5 you will suddenly see the threads go up to 20 before throwing an java.util.concurrent.RejectedExecutionException. Nice, but what the hell happened?

Let’s dig deeper in the documentation of the thread pools:

thread-core-pool-size: Specifies the number of core threads in the EJB container’s common thread pool. The default value is 16. Great, there we have our number 16. Setting this to 10 oder 100 will change the actual number of threads doing some work.

thread-max-pool-size: Specifies the maximum number of threads in the EJB container’s common thread pool. The default value is 32. Nice, increasing this to 100 will be the maximum number of threads we can use? Yes and no. You have to consider the default-value of thread-queue-capacity.

thread-queue-capacity: Specifies the size of the thread pool queue, which stores new requests if more than thread-core-pool-size threads are running. The default value is the Integer.MAX_VALUE.

Here starts the confusion. Your queue-capacity is way too high. Pressing F5 will never reach MAX_VALUE, so your core-pool-size never change nor scale. You must limit your capacity first before the thread-pool is scaled with maximal max-pool-size threads. In our example, we will scale when we reach 25 waiting requests. It will scale up to 20. When all threads are used in parallel the container throws an exception.

In the past SUN declared correctly: “That is exactly how it is supposed to behave. First the threads grow to coreSize, then the queue is used, then *if* the queue fills up then the number of threads expands from coreSize to maxSize. Hence if you use an unbounded queue the last part never happens. This is all described in the documentation. If you want an unbounded queue but more threads then increase the core size. Otherwise consider whether a bounded queue is more suitable to your needs.”

Some extra information can be found here https://java.net/jira/browse/GLASSFISH-17735 and http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html.

Advertisement

A basic outline of a workflow system using J2EE and CDI

Posted: April 15, 2013 in CDI, Glassfish, J2EE, Workflow
0

For one of my customers, we needed a very simple workflow-framework which coordinates the flow between methods inside a J2EE6 application on Glassfish. The business required to implement the following simple logic:

  1. Create a job.
  2. When step 1 was successful, then start a job (which affects some thousand objects) and send an email
  3. End a job when step 2 was successfull.
  4. Mark the job as failed when one of the steps couldn’t be completed due to the implemented business-logic.
  5. Provide a handler to handle exceptions.

Taking a fully fledged workflow-system was way over the top to solve this problem. The workflow will also remain unchanged; and when it is changed, the code needed to be altered to. We needed to come up with a simple workflow-management which is bound to transitions and methods.

So, first we decided to create an observer the change the transitions of the workflow-steps. This is basically a very simple method which alters the status and stores it in the database. The next step was to create some annotations to add to the methods which needed to be executed during a certain step. We annotate our workflow methods as follows:

@Asynchronous
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
@Workflow
@WorkflowStep(from = Status.IDLE, to = Status.PROGRESS)
public void startJob(@WorkflowActionHandler
                     @Observes(notifyObserver = Reception.ALWAYS,
                               during = TransactionPhase.AFTER_SUCCESS)
                     final JobWorkflowEvent event) {}

This straight-forward approach is very clean and simple. Basically it says that this method will be executed after the transition from a Status.IDLE to Status.PROGRESS. Although we use an enum here, you could take any arbitrary integer. Using the CDI annotations we get some additional power. This method will only be executed after the success of the previous step. Here you can combine the full power of CDI with some basic workflow concepts to create a nice system.

Now remains the problem of the transition handling. The transitions are handled in an interceptor which is marked by the @Workflow annotation.

@Interceptor 
@Workflow
public class WorkflowInterceptor {

}

This interceptor does not do much more than changing the transition state when the method pinged by CDI has the correct workflow-steps. It uses some reflection to figure that out and allows access to the method.

To handle exceptions, we introduce a new annotation:

@Asynchronous
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
@Workflow 
@WorkflowException
public void excJob(@WorkflowActionHandler 
                   @Observes(notifyObserver = Reception.ALWAYS,
                             during = TransactionPhase.AFTER_FAILURE)
                   final JobWorkflowEvent event) {
}

Whenever one step fails unexpected, control is transferred to this method where certain actions can be executed. We need this annotation to prevent other methods to pick this event up. 

Using CDI together with some custom annotations really did the job and works fine.

JPA, Criteria and custom objects

Posted: April 15, 2013 in Glassfish, JPA, SQL
0

Suppose you have a SQL-statement where you select custom fields and or the result of some functions. To make it more interesting, we want to combine this with a group-by statement and an ordering. Let’s us for example say you want to execute the following query in MySQL:

SELECT uuid, GROUP_CONCAT(field1, ':', field2),
       MIN(ss_date_started), 
       MAX(ss_date_ended) 
FROM my_table 
WHERE key = 'xxx' 
GROUP BY group_key 
ORDER BY id ASC

The functions GROUP_CONCAT, MIN and MAX are availble in MySQL. The intention of the GROUP_CONCAT is to get some information out of all the group-rows with issuing additional selects. The question is how we can create the criteria for this query and how we can retrieve the results.

We want the results to be stored in the following object:

public class MyGroup implements Serializable { 
    private String uuid;
    private Map map = new HashMap();
    private Date dateStarted;
    private Date dateEnded; 

    public MyGroup() {
    }
}

In the map we want to store the GROUP_CONCAT strings as a map to avoid other SELECTs. First of all, we get the CriteriaBuilder and the root of the query. The MyEntityForTheTable is the entity which is mapped to the table. This object will act as the base to map our fields.

final CriteriaBuilder cb =
   this.getEntityManager().getCriteriaBuilder();

final CriteriaQuery cq = ...; // we'll talk about this later

final Root root = 
  cq.from(MyEntityForTheTable.class); 

The WHERE clause is pretty simple:

cq.where(cb.equal(root.get(MyEntityForTheTable_.key), key));

The GROUP-BY and the ORDER-BY is even more simple:

cq.groupBy(root.get(MyEntityForTheTable_.groupKey)).
   orderBy(cb.asc(root.get(MyEntityForTheTable_.id)));

Now we need to construct the function calls. We extract the MIN and MAX date out of the group using by writing the following expressions:

cb.function("MIN", Date.class, root.get(MyEntityForTheTable_.dateStarted));

cb.function("MAX", Date.class, 
   root.get(MyEntityForTheTable_.dateEnded)) 

We start with the GROUP_CONCAT in MySQL which can be written as:

cb.function("GROUP_CONCAT", byte[].class, 
    root.get(MyEntityForTheTable_.field1), 
    cb.literal(":"), 
    root.get(MyEntityForTheTable_.field2))

First of all, we cannot take String.class to read out the results. MySQL returns the string as byte-code, so we need to map it to a byte[]. The following arguments are the parameters for the function. The first and the last is the result of the columns. We also want to have a semicolon between the two values which can be achieved by cb.literal(String) function.

Now we need to execute the queries and map it to an object. We can use the construct() method to instantiate a new object inside our query. Unfortunately, our main domain object does not have the proper constructor. So we wrap the POJO class in a new class and add the specific constructor.

public static class WrappedGroup extends MyGroup {

  public WrappedGroup() { }
  public WrappedGroup(
     final String uuid,
     final byte[] serviceStatus,
     final Date dateStarted,
     final Date dateEnded) { }
}

We make sure that this constructor has the byte[] parameter. In this constructor we can convert the byte-array to a string. The you can convert the string to a map of your choice. So, we are almost done. Here is the complete code:

final CriteriaBuilder cb = 
  this.getEntityManager().getCriteriaBuilder();

final CriteriaQuery cq = 
  cb.createQuery(WrappedGroup.class);

final Root root = 
  cq.from(MyEntityForTheTable.class);

And the select part looks like;

cq.select(cb.construct(WrappedGroup.class,
   root.get(MyEntityForTheTable_.uuid), 
   cb.function("GROUP_CONCAT", byte[].class,
      root.get(MyEntityForTheTable_.field1), 
      cb.literal(":"), 
      root.get(MyEntityForTheTable_.field2)),
   cb.function("MIN", Date.class, 
      root.get(MyEntityForTheTable_.dateStarted)),
   cb.function("MAX", Date.class, 
      root.get(MyEntityForTheTable_.dateEnded)))); 

We then use a TypedQuery to get the results, and we are done:

final TypedQuery query =
   this.getEntityManager().createQuery(cq).
   setFirstResult(startResult).
   setMaxResults(maxResults);

The resulting list can be cast to List.

Et voilá, we have a very dynamic query which we can easily refactor and adapt.

Is a @Singleton bean really a singleton?

Posted: April 15, 2013 in Glassfish, J2EE, Singleton
0

Well, as you might have expected from the title, the answer is “yeah well, not really”. A singleton in the J2EE world is not a singleton as you know it from the normal Java world. In a non-J2EE environment you typically write something like this to generate a singleton:

public class MySingleton {
  final private static MySingleton instance = new MySingleton();

  protected String name = "whatever";

  private MySingleton() {}

  public static MySingleton instance() {
    return instance;
  }
}

You can get exactly one instance of this bean and you could access the fields directly or through getter and setters. There is only one instance of this object and all information is stored there. This pattern is well known to every programmer. The demand was great to port this pattern to the J2EE world. A new type of bean was invented, the Singleton bean. The idea behind all this is to provide a single instance of a particular bean within your application. You can construct a singleton bean with the following code:

@LocalBean
@Singleton
@Startup
public class MySingleton {

}

First we declare it as a local bean, and we load it during startup. The @Singleton annotation makes a singleton out of this class. But is this class really instantiated once when using the @LocalBean annotation? No, it is instantiated twice! Let’s test this out with by adding a static field in the bean.

static int i=1;</pre>
public MySingleton() {
    System.out.println("INSTANCE: " + i++);
}

You will see in the logs that you get two different instances. If you print out the reference of the class, you will notice that one of the instances is a proxy object. The proxy object is instantiated too and the constructor is instantiated again. When you write some kind of initialisation logic inside the constructor, you will run into somekind of unwanted behaviour because it executes your code twice where you expect that the constructor is executed only once. So, don’t use the constructor to set up your data but use the @PostConstruct annotation to execute a method with your initialisation logic in it.

@PostConstruct
public void init() {
   ... do your init here ....
}

You will see that the proxy object does not execute this code (which is obvious of course because the code is not in the constructor anymore). Another pitfall might be that during some kind of rapid prototyping action you store some state-data in a non-private field in the singleton or a stateful session bean. When you do not provide a getter/setter for the field, the field-value of the injected bean will always be null because the proxy gets injected and not the “real” instance. The proxy object does not store state. Let’s test this:

@LocalBean
@Singleton
@Startup
public class MySingleton {
    protected String name = "whatever";
    .....
    public String getName() {
         return this.name;
    }
}

We inject this bean in another session:

@LocalBean
@Stateless
public class MyTest {
    @EJB private MySingleton mySingleton;

    public void test() {
        // mySingleton.name --&gt; null; (proxy)
        // mySingleton.getName() ---&gt; "whatever" (real object)
    }
}

The injected reference is the proxy object without state. Getting the value of the field directly must always return null when it is not initialised. The real state is maintained in the singleton. You can get the “real” data when you use the method “getName()” because the proxy object tunnels your method and not the field. This is the reason behind the fact that you may not use fields directly in session-beans.

Well, as you might have expected, it is really a bad idea to get the field from a singleton or other bean directly (in general, it is an anti-pattern in J2EE). Try to encapsulate your data with nice getters and setters and keep in mind that your objects can get dynamic proxies depending on the annotations you add to the class.