I'm sitting in a session on clustering. I'm interested in this topic because I'm going to try and setup Tomcat clustering for Roller. Furthermore, I'm going to try and do it between my current ISP and Groove Systems. Rather than just hopping ISPs, I figured it would be easier to setup a highly available system. I was talking to Dave last night about setting up clustering on JRoller.com. The main problem there is handling file uploads. A lot of folks have uploaded files, and if you setup a cluster, you'll either have to do it on the same machine or mount the first machine's "resources" directory onto the second machine. Regardless, I doubt it would be that difficult.
A typical cluster architecture has a firewall, followed by load balancers that proxy to a webserver farm. Then there's another firewall that talks to J2EE app servers that talk to a highly available database.
Gotcha #1 Apps don't have to be cluster-aware do they?
In a perfect world, this can be true. Programming model issues: serializability and handling failures. HTTP Session and EJB Stateful Session bean state. Tip: Serialize only when needed. Here's a personal tip - add <distributable> to your web.xml file. In most cases, you're appserver will tell you when objects in the session are not serializable. It's a simple way to test if your application is ready for clustering.
Gotcha #2 Idempotence
I missed the definition but it seems to be the ability to do something again and again and get the same results. Here's the real definition of idempotent. Basically, can your application handling retrying something?
Gotcha #3 Using the session or SSB's state as a database
The session is designed to handle conversational state, not information that might need transactional attributes. Stuffing a large volume of data in the session is just a memory issue on a single server - but it becomes a performance issue in a cluster.
Gotcha #4 Upgrades/Patches without impacting availability
Tip: Rolling upgrades and Quiescence. What is quiescence? It's the ability to prevent new users from coming into your app while upgrading, while continuing to service existing users. Quiescence in clustering refers to the ability to bring down servers, upgrade them, and re-introduce them to the cluster.
This talked switched speakers about 10 minutes ago. The new guy is talking about how vendors might implement clustering solutions. In other words, it's boring and doesn't interest me. I care about what I need to do to deploy to clustered servers.
Now we have another speaker - to talk about performance. Performance is always addressed at the end isn't it? Even in the real world. It was funny talking to Dave last night about JRoller. He said that Matt and Rick setup Roller on a test box and hammered it while there were trying to figure out issues. The hit it more often then the production JRoller instance gets. Unfortunately, there were unable to reproduce any issues. The main things that Dave did to fix the latest release was to remove OSCache and to remove Roller's Query API. Now it uses Hibernate directly (I'm guessing that Castor is no longer a persistence option).
That's it - session is over. Now onto learn more about JNDC.