Glassfish b45 review

I've been playing with Glassfish for a while now, for a number of reasons: I need to learn Java Enterprise Edition (the new specifications), I want to find out what I can expect from Sun Application Server 9, and – lastly, perhaps most important – I have a requirement for an application that will make my job easier and my output better.

So far, Glassfish has been quite nice, except for a few issues. Overall, memory usage is acceptable; the console is functional, and the APIs implemented are, obviously enough, the standard by which everything else will be judged (since it's the reference implementation for Java Enterprise Edition.)

The user community for Glassfish is very responsive. I've fired off a few boneheaded queries to the mailing list, and gotten very rapid response (in two cases, resulting in bug reports, and in other cases, resulting in explanations of why my code was, well, wrong.) The community was quite impressive.

However, there are still areas that could use improvement, and a few showstoppers.

For one thing, the database pooling seems to be a little... unreliable. I've encountered a number of cases where, using only the persistence engine (i.e., EJB3), I've run out of available connections for a given pool, and the application server is unable to recover. This has been seen with the bundled JavaDB (a version of Apache Derby); I haven't tested other databases, partially because I'm specifically limiting myself to the Glassfish bundle for the moment.

I've seen the same behaviour with multiple redeployments of a fairly large enterprise application, but given the occurrence with a fairly stable (and small, clocking in at 2.1MB) application, I'm of the opinion that the database pooling mechanism isn't quite up to standard yet. (This is unconfirmed, mind you. I could be completely wrong, and my code might be leaking connections like mad – but I'm not actually managing any of the connections, so I doubt it.) The hang is very frustrating, as it pegs the CPU at 100% usage, which makes the process a bit difficult to kill.

The application I'm using as a test leveraged JMS quite a bit – a single web page change can fire off forty messages, and those messages might result in 400 new entities being created, or 400 changes to existing records. (Or more, honestly.) This would have been classified as a horrible abuse in EJB 2.1 or earlier, potentially creating massive scalability problems, but Glassfish handled the simpler test cases with no problems, with the exception of the server hang mentioned previously. When the application I'm testing runs, it runs very quickly.

JSF runs very well in the application server. I have not had a chance to profile it yet, but the console application is using JSF itself, and it's very responsive.

The console functionality itself is sufficient. There are a lot of monitoring options, and logging controls are built into the console. The only gripes I have about the console are in deployment capabilities (specifically, I'd like the ability to tie local JNDI references to server references at deployment time, through the console) and certain diagnostics (i.e., “how many JDBC connections am I using?” and the ability to examine the JMS queues through the console.)

Documentation on Glassfish is still a little odd. It tends to be spread across multiple documents (a la the traditional Sun documentation method) and focuses fairly rarely on being task-oriented. However, once the general concepts behind Java EE development and deployment are understood, the console makes the tasks easy enough.

It should be noted that some people are using Glassfish in production, despite its unreleased state and the issues I've found in it. Overall, I've found Glassfish to be sufficient for learning Java EE, and I have high hopes for the few flaws it has being fixed in the near future.

tags: java  glassfish  review  java ee