Oracle Glassfish 3.x issue in EJB 3.1 with @Asynchronous methods

Recently, as a pet project, I’ve been working on an application that uses the @Asynchronous method level annotation in a Singleton EJB as per the EJB 3.1 specification. The application consisted of a call to a restful URI, to capture an xml representation of an object, converting this into a POJO (Serializable) then sending it to a MessageQueue as an ObjectMessage. Each datum was independent, and there was a high volume of data to process, I decided to implement the new method level @Asynchronous annotation, the fire-and-forget way. I also built an MDB as a consumer of the Queue, that is however irrelevant to the issue.

Of course this EJB 3.1 application had to be load tested for large volumes of sample data. I’ve made up a test sample that was representative of the projected volume of data, and set the @Asynchronous method’s Thread.sleep() for 5 seconds. The reason for this was to estimate a worst case scenario for the Request-Response lifecycle. The app was deployed into Oracle Glassfish 3.1.1 with tuned EJB and MDB pools, and a somewhat starved 768MB max heap.

While watching the log output, I noticed that the @Asynchronous threads were spawned by bunches of 16. I tried to further tune EJB Thread pools inside of Glassfish — with no luck.

I found the issue on the Glassfish website after checking out the current stable codebase from their subversion repository. In Oracle Glassfish 3.1.1, according to the EjbAsyncInvocationManager.java class in com.sun.ejb.containers the 16 thread limit is hard-coded.

public EjbAsyncInvocationManager() {
   //TODO get the paramters from ejb-container config
   super(16, 32, 60, TimeUnit.SECONDS, new LinkedBlockingQueue());
   super.setThreadFactory(new EjbAsyncThreadFactory());
}

I’ve checked out the latest stable glassfish (Maven is great, isn’t it?) project, then as a duck tape solution, increased this number to satisfy my application’s needs. As soon as I have time to devote to this issue, I’ll investigate what the best way to fix this would be. I think the least impact to the codebase would be to include the settings for min-max thread-pool size and timeout values in glassfish-ejb-jar.xml somehow nested in the definition for an EJB.

One thought on “Oracle Glassfish 3.x issue in EJB 3.1 with @Asynchronous methods”

  1. Hi,

    I’ve been working around this issue, but i didn’t find yet if there is a solution for this. Do you know if this bug its fixed?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>