Comparing OpenEjb and Glassfish

Question

can we replace Glassfish with Tomcat/OpenEJB for lighter applications? What is the performance of OpenEJB comparing to glassfish as EJB container.

What is the restrictions of OpenEJB instead of glassfish?

Regards

Sagacity

Answer 1

I guess the question is about the runtime environment but still, I don't understand what lighter application does mean. Memory footprint? Startup time? Deployment time? What problem do you actually have? And please define light.

For what it's worth, I consider GlassFish 3 as a light runtime and my experience with it is very positive. From the product data sheet:

Oracle GlassFish Server 3 implements the OSGi runtime, which allows features to be dynamically added to the Java server as needed, and for the smallest possible Java stack to be deployed to support applications. This helps to keep the footprint as small as possible by loading only the modules required to service deployed applications—improving startup time and reducing resource utilization.

Second, I personally don't like the Frankenstein approach, I believe that the glue between all parts that you get with a real application server is part of the added value, that's actually why I use an app server.

Third, I never benched OpenEJB, I used it for testing only and never planned to use it for production, mostly because of its bad reputation. See this comment about Geronimo's performances on TSS (from Hani Suleiman, don't be surprised if it's caustic):

I'd imagine that saying that the EJB tier is 'acceptable' is about the nicest thing you could say.

From what I know, geronimo's ejb code is based off openEJB, which has, historically, bean the worst container you could possibly find. You'd have to look pretty hard to find it too, only to be filled with various degrees of regret/rage once you achieve that dubious goal.

It's not surprising that G's performance will always be sub-par. The frankenstein approach of software building is a great recipe for bad performance. Sure, you'll have lots of pretty diagrams, great looking dependency graphs, and loose coupling. All of which are fairly irrelevant to users who want a coherent appserver that they can treat as a black box.

Things might have changed, OpenEJB has probably improved, at least a bit, but still:

• OpenEJB doesn't fully support EJB 3.1.
• Tomcat + OpenEJB is still not a full Java EE implementation, you might still have to add some pieces to your creature (not even mentioning Java EE 6).
• And what about the administration, clustering, etc?
• If you don't need the full Java EE 6 profile, there is the Java EE 6 web profile
• I'm happy with GlassFish 3, I don't find it "heavy" (and I suggest to try it).
• I know it can perform well.

For all these reasons, I wouldn't consider Tomcat+OpenEJB instead of GlassFish, especially if there is no problem to solve.

Related questions

• Which technologies does Tomcat support
• What is an Enterprise Java Bean really?
• Real world comparisons of Glassfish and JBoss 5?

See also

• GlassFish 2 vs. Tomcat 6
• Putting GlassFish v3 in Production: Essential Surviving Guide

Jeminah

In all fairness this evaluation is more a statement of what you don't know about OpenEJB: pieces required to make a full server, admin/clustering capabilities, performance. They are still fair statements as the project should do a better job of presenting that information. That said, the post is still phrased as an evaluation and does somewhat discourage people from evaluating what you did not. You quoted Hani as some you respect, just many people here respect you and will quote you. As a small project, it's very difficult for us to compete against that. We only ask for a fair shake. – Usm

Answer 2

Note that Hani's comment was in regards to Geronimo 1.0/OpenEJB 2.0. Hani was wrong in the frankenstein comment as the OpenEJB 2.x codebase was built entirely from scratch for Geronimo and as a result it only ran in Geronimo; the embedded, tomcat, and standalone modes were all lost. We found Hani's comment was right in that the performance was not good.

For OpenEJB 3.x we abandoned the 2.x codebase and picked things up from where we left off in OpenEJB 1.x and brought it up to EJB 3.0 certification. 2.x and 3.x share no code. OpenEJB 3.x turned out very well and the project has been growing pretty rapidly since the first 3.0 release in 2008. The EJB 3.1 Embedded Container and EJBs in .wars features came from OpenEJB. We had the first @Singleton implementation and hope to complete the rest of EJB 3.1 and certify web profile by Q4 this year. Failover and JMX monitoring have been under heavy development since January, are now complete, and will be released in 3.1.3 in a couple weeks. The failover is actually second generation, the first failover support was released in 3.1.1. There was significant remote performance work done in the 3.1.1 release as well bringing RPC calls up to a mean of 7300 TPS in our benchmarking.

Less important to some, but very important to others, Apache OpenEJB is not a corporately controlled open source project. The majority of committers are users who have earned commit and use OpenEJB at work. This has its advantages and disadvantages, but the bottom line is OpenEJB is filled with people who love it and use it and the community is just as open as the source.

UPDATE

In October 2011, we obtained Java EE 6 Web Profile certification with "Tomcat+OpenEJB", now called Apache TomEE.

Certified and with a clearer name, we hope this makes the stack easier to both understand and compare.

On a personal note, I view the comments in this thread as one of the major motivators for taking the certification step. Thank you to everyone at StackOverlfow for feedback which I find both encouraging and grounding. Connecting with this community has resulted in so much positive change in OpenEJB/TomEE.

Usm

Answer 3

In my brief tests, I found glassfish not light enough for my needs (startup time and memory usage). I have been happy with openejb so far.

Bonny

Interesting. Embedded GF (full profile) starts in less that 3s for me (see also adam-bien.com/roller/abien/entry/embedding_ejb_3_1_container and blogs.sun.com/arungupta/entry/…) – Jeminah

Thanks, I'll try it out again at some point. Thats the beauty of java-ee : as soon as I can prove one server meets my needs better than another, I can fairly easily swap vendors :) The competition between them is good and its nice to have containers with slightly different goals - thus java-ee can cater for a greater variety of needs. – Bonny

Answer 4

Really interesting post. That was exactly our (company) opinion before trying OpenEJB 3.0, three or four years ago!

We now have a good experience with OpenEJB and it's widely use in production/development. It's really light and easy to use. Thanks to OpenEJB, developers save a lot of time (Matthew B. Jones' posts are also a nice feedback).

The community is active, open minded and all the time ready to help and improve the product with useful features coming from real feedback of users.

And last but not least, performances are actually great!

Jean-Louis

Annmarieannnora

With all due respect, you could at least mention that you are an OpenEJB committer, for total transparency. – Jeminah

It should have been mentioned -- it's a good part of the story. Company spends a year+ evaluating options. Company picks option (OpenEJB). Company starts using it. People from company start getting involved (mostly Jean-Louis). Jean-Louis earns commit (one year ago in June, in fact). That's how all open source stories should go. – Usm

Answer 5

OpenEJB as a lightweight and embedded alternative to stand-alone application servers. We ported our application from JBoss and Weblogic (it had to support both) to Tomcat/OpenEJB without major problems. The performance tests showed gains or not worse results.

The biggest restriction of OpenEJB is incomplete documentation. Its web site is ok (it's actually pretty decent for open source project) but it can't compare to JBoss, Glassfish, etc.

Another thing that you should be aware of is that it uses ActiveMQ as a JMS provider, which is another open source project. The integration with ActiveMQ is nice but presents some restrictions. For example, you can't just upgrade to latest release of ActiveMQ.

Once again, as always in open source lack of support and documentation is compensated by free access to sources and developers who write it.

Clavicle

Hi grigory. The MDB pooling is actually done by the Resource Adapter (ActiveMQ in this case). Try adding this to your MDB --- @ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "5") --- Basically, the InstanceLimit property of the MDB Container is there to protect against naive Resource Adapters that don't know it's their responsibility to pool and instead continuously draw new instances and never clean them up. I have a recent blog post on the MDB/Connector relationship which might be interesting to you: bit.ly/bym3SC – Usm

@David Blevins - thank you for the advice. I was looking for something like this without any success so I'll give it a try. Actually, I posted my question on OpenEJB forum - openejb.979440.n4.nabble.com/… - with no replies so far. – Clavicle

You have no idea how grateful I am you pointed that out. Seems there's a bit of a Nabble epidemic bit.ly/crwNcL Steer clear of Nabble for a while, I'll try to keep a close eye here. – Usm

@David Blevins Could you point me to any examples of using <activation-config> within ejb-jar.xml (or should I use openejb-jar.xml?)? – Clavicle

Add the system property 'openejb.descriptors.output=true' and OpenEJB will output a descriptor that exactly matches all your annotations. The very best way to do overrides without having to type anything. Here's an example generated file gist.github.com/673797 – Usm

Answer 6

I think I stand by David Blevins in the sense that Glassfish now means Oracle, and we all know the legacy they left behind with OC4J. I fear Glassfish may require more and more hardware for the same service.

Anyway the best advice is: Set up a Benchmark and try both solutions yourself, it is a matter of no more than 20 hours of expert work.

Muley

While I agree with the last part of your answer, the first part just sounds like FUD. – Jeminah

R.L.H. just analyzed history and made educated guess about the future for Glassfish. I can't agree more with him. – Clavicle