Clustering a stateless Java EE application with Glassfish on Amazon AWS

Question

What's the best way to deploy a stateless Java EE 6 application in a distributed environment in order to achieve high availability and scalability? My application is stateless. Therefore, I don't need to replicate any session state (HTTP session, EJB stateful beans, etc.)

Specifically, I'd like to know the following:

• Do I need the clustering capabilities of Glassfish 3.1 (given that I don't need to replicate session state)?
• I'm heavily using JMS Queues and Message Driven Beans. How do I setup JMS to make it work in a clustered environment?
• I'm also using the EJB timer service. How does that work in a clustered environment? Is there anything I need to do besides using a shared DB for storing timers (and not the embedded Derby DB)?

I plan to use Amazon AWS (RDS with multi AZ deployment, elastic load balancing, EC2).

Answer 1

I'm in a similar situation, and I'm currently discovering what GF clustering can / cannot do for me.

Re 1) Do I need the clustering capabilities of Glassfish 3.1

Since your EJBs are stateless, you don't need a GF cluster for session/state replication (as you say yourself). You could just setup multiple standalone instances and deploy your app to them individually. However, even in a stateless application, I find the benefits of a GF cluster very worthwhile - from an administrative point of view.

The GF Cluster will ensure that the configuration is automatically applied to all instances. JNDI is replicated automatically. Applications are deployed automatically. It's a single command to scale out and add an additional instance - a short while later, your cluster is extended and the new instance is configured, deployed, started and ready to go. For me, that's administrative heaven and reason enough to use a GF cluster whenever I have more than 1 instance!

One thing to consider (and I'm struggling with this badly at the moment) might be a distributed/coordinated L2 cache, in case your application is talking to a database.

Re 2) ... How do I setup JMS to make it work in a clustered environment?

Not sure I understand your question... If you want to have a high available message broker outside of GF, you'd need to set it up accordingly and manage it by yourself. For example, ActiveMQ has several ways of setting up clustering/HA/scale-out. If you use the GF-provided OpenMQ, setting up a GF-cluster also provides a clustered message broker. Out of the box.

But broker clustering is a topic in itself, and not to be underestimated. You might need to think about persistence and a shared message store and such - regardless of using an external or the GF-provided-and-clustered broker.

If JMS is such an integral part of your application, I'd recommend appropriate attention to the broker. I probably wouldn't use the GF-broker, but rather have a separate broker-cluster (separation of concerns; e.g. you can upgrade GF / broker independent of each other).

Re 3) EJB timer service ... Is there anything I need to do besides using a shared DB for storing timers?

If you require timers to automatically fire only once in your group of (appserver-)instances, I believe you do need GF clustering (plus the shared DB of course). Otherwise I do not see, how each instance should know if it should fire or not. However, this is easily tested...

tl;dr

• Use GF clustering to save on admin work
• Use an external, well-understood high-available message broker
• Use a shared DB for your EJB timers

Answer 2

My perspective on your respective points:

1) session replication is a part of cluster management, its not the goal of creating clustered server environment. The benefits you get out of clustering are :

• Improved scalability
• Higher availability
• Greater flexibility Side-effects of clustering are increase in infrastructure complexity, additional design and code requirements etc. So if you are thinking about clustering then your decision should be driven by the factors like how scalable, available and flexible you want your application to be.

2) You can use Apache ActiveMQ with you glassfish server to make your JMS thing working in clustered environment.

3) I think shared DB should suffice