Slashdot Mirror
Building a Stable and Clustered J2EE Environment?
royles asks: "I am working with several J2EE Application Servers and all seems fine until I start to scale and cluster. The goal is to ensure a web and EJB session is maintained across a pool of Application Servers. The level of complexity to achieve this straightforward requirement is proving too much. It quickly becomes evident that vendors claims of 'robust and scalable' go straight out the window in favour of extortionate support and consultant costs when the installation becomes large. Anybody else experienced this type of problem? What are other peoples experienceâ(TM)s in this area? Any recommendations on Application servers that âdo what they say on the tinâ(TM)? Any good online resources for achieving a highly scaled and robust solution?"
First of all, do not store data on the application server. Secondly, make sure that all of your objects associated with a session in either the EJB layer or the HTTP session implement Serializable.
;-)
I'd recommend running JBoss + Tomcat on Linux with Apache frontending it with mod_jk2. Put all your static web content on Apache to free up Tomcat. The easiest way to do this is to use a load-balancing solution in front. Have it pass the sessions through to the Apache server which will offload any JSP/Servlet requests to Tomcat. Have the JBoss/Tomcat installation on each node of the cluster clustered using JBoss' JavaGroups based clustering. You can also use the JBoss Farm service to deploy the EAR file to one node in the cluster then have the other nodes pick it up from there.
If you use a seperate set of machines for the database cluster than the JBoss/Tomcat nodes can be set up as copies of each other with no data on board. Using Linux boxes, this is easy (dd the drives). If a node goes down for some reason, swap it with a spare. Any session info is already serialized and passed to the other nodes in the cluster, and the load-balancer w/ failover should handle the client end of that.
By the way this thing scales to at least 100 boxes from the stories I've heard. I've done it my self in small (5 box) installations. I've also used F5 equip for the load balancer/failover on the front. Everything worked well.
Buy the JBoss docs to help with the clustering. I've also got some docs I wrote on setting up JBoss clustering somewhere around here.
You'll be suprised how simple clustering is with JBoss once you understand a bit how JBoss works and is configured. You will also be amazed at how well it works.
The best part of course is that it's all Open Source, so no license fees. Hell, I'll set it up for you for 30% of the licenses and support you would have bought if you want.
Arrogance is Confidence which lacks integrity. -- me
Clustering *is* hard. And even the best application server in the world can't reduce that complexity. It can just try to not add any complexity of it's own.
Front-end load balancing, internal load balancing policy, cache settings, fail-over settings, setting up the LAN correctly... these are all *extra* things you need to do under a clustered J2EE server that you don't need to worry about normally. Clustering is hard
Having said that, I've been involved in commercial projects using clustering under Weblogic and JBoss. We have been able to get them going without too much trouble.
Also, some things J2EE allows some things in non-clustered mode that it explicity warns won't work in clustered mode. For example, objects in Sessions must be Serializable when clustering.
=Matt
http://www.onjava.com/lpt/a/1517
Slashdot = Sarcasm
EJBs are going to be in a guarenteed transactional state throughout the cluster, which simplifies all of your access. The containers should be caching some types of beans as well (CMP), so that you end up with a very fast transactionally complete solution across the environment. You can use JDO or other data solutions, add your own cache, manage it across the cluster.. and that may work well for you. Other beans are useful, such as the Message Driven Beans, for building a J2EE standard event driven component. Straight data mapping solutions don't provide this.
That said, personally I find many people don't need to worry as much about clustering, so as long as you are working on a good environment, thats probably more important. I use hibernate more these days with a good solid MVC design. I have servlets set to start at boot that become by queue listeners, and it works quite well. I can use XDoclet to generate my hibernate mappings if I want, and get up and running quickly.
The good thing is that you have alot of options. The bad thing is that you have a lot of options.
It comes down to picking the right technology for the job.. and your team. JDBC, JDO, OR-Mapping, EJB, etc all provide good tools to complete the job.
Agreed, but in my opinion any application which needs heavy multi-user data processing (think OLTP) is better served with the more "traditional" way of doing things: let the RDBMS do the transactions and cacheing, because they do it best. Call me a data modeler or SQL buff you like, but I still fail to see the advantages in letting the "application server" do these kind of things.
About the only thing I see useful in EJB (vs. POJO+JDBC) is that they give you the networking infrastructure to make them remotely callable, so that you don't have to mess with RMI or the like.
A good article I read recently by Martin Fowler, "Domain Logic and SQL" covers some of these points, and reinforces my opinion that neither EJB nor any other O/R mapping tools are suited for heavy OLTP apps. Or am I missing something?