Tag: EJB

Is Asynchronous EJB Just a Gimmick?

In previous articles (here and here) I showed that creating non-blocking asynchronous applications could increase performance when the server is under a heavy load. EJB 3.1 introduced the @Asynchronous annotation for specifying that a method will return its result at some time in the future. The Javadocs state that either void or a Future must be returned. An example of a service using this annotation is shown in the following listing: The annotation is on line 4. The method returns a Future of type String and does so on line 10 by wrapping the output in an AsyncResult. At the point that client code calls the EJB method, the container intercepts the call and creates a task which it will run on a different thread, so that it can return a Future immediately. When the container then runs the task using a different thread, it calls the EJB's method and uses the AsyncResult to complete the Future which the caller was given. There are several problems with this code, even though it looks exactly like the code in all the examples found on the internet. For example, the Future class only contains blocking methods for getting at the result of the Future, rather than any methods for registering callbacks for when it is completed. That results in code like the following, which is bad when the container is under load: This kind of code is bad, because it causes threads to block meaning that they cannot do anything useful during that…

Read more

Taking Advantage of Parallelism

A while ago some colleagues attended a lecture where the presenter introduced the idea that applications may not take full advantage of the multi-core servers which are available today. The idea was that if you have two cores but a process which is running on a single thread, then all the work is done on one single core. Application servers help in this respect, because they handle multiple incoming requests simultaneously, by starting a new thread for each request. So if the server has two cores it can really handle two requests simultaneously, or if it has 6 cores, it can handle 6 requests simultanously. So multi-core CPUs can help the performance of your server if you have multiple simultaneous requests, which is often the case when your server is running near its limit. But it's not often the case that you want your servers running close to the limit, so you typically scale out, by adding more nodes to your server cluster, which has a similar effect to adding cores to the CPU (you can continue to handle multiple requests simultaneously). So once you have scaled up by adding more cores, and scaled out by adding more servers, how can you improve performance? Some processes can be designed to be non-serial, especially in enterprise scenarios. The Wikipedia article on multi-core processors talks about this. Imagine a process which gathers data from multiple systems while preparing the data which it responds with. An example would be a pricing system. Imagine…

Read more

EJB Frustrations

This is by far not the first time I had worked on a project with EJBs (Enterprise Java Beans, see http://java.sun.com/javaee/), so why am I still amazed at the time wasted in the development of them, relating to configuration issues, compiling time (double compilation due to RMI requirements), slowing down of development environments due to the vast resource requirements of application servers, and obscure error messages? That last point deserves expansion - on Websphere, not only do you sometimes get strange CORBA related error messages on the client which have absolutely nothing to do with the problem, but you also get orb trace files secretly dumped with no warning! And similar on the server with the ffdc traces that get dumped, with a very simple warning message printed in the logs... I recently reviewed our current system to ensure that errors in logs were extremely concise and at the same time provide the exact details that second and third level support needs to resolve problems. Unique error codes, showing the customer the timestamp to report, User messages as well as technical messages in the logs for support staff, and so on. Shame application server vendors couldn't do a little more to make developing on their systems somewhat more efficient...

Read more