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?"
"If you upgrade each of your current servers to the quad-processor GigaFLex, you'll have no problems."
"Do you have any perfomance metrics for that? How about a customer we could reference on that?"
"Ummm, no... those results are from our research lab."
(you get the idea)
Isn't the purpose of EJB to meet these sort of goals without having to do anything special? Well, except architect your app. a certain way. If doing this is non-trivial then doesn't it mean that EJB has failed to a certain extent? If I have to hear about Data Transfer Object Factories and CMP entity beans again I think I'll puke....
Actually, some appservers (WebSphere?) *do* have "click here to cluster" buttons.
The problem is that they don't work.
first, let me say that I am a huge fan of Resin. I looked at the major servlet/JSP containers about a year ago and found Resin to be the top (mostly in terms of price/performance).
That said, Resin is *not* a "set and forget" solution, unless you are happy with the default configuration. It takes some trial and error for tuning, and the error messages it gives don't typically make the real problem obvious at all.
Their documentation is lackluster, but you can generally find the answer you need if you are willing to look hard enough.
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
You can use a Cisco localdirector(s) at the front of the farm of your application servers, and just enable sticky cookies. This will cause the localdirector to keep the requests on the same application server, and reduces the complexity of having to implement software load balancing solutions in your code and on your servers.
"And I for one welcome our new insect overlords."
You create a 'server group' and add clones to it with mouse clicks. Viola, instant-on, growable/shrinkable massively scalable J2EE container.
Maybe this guy is trying to use the "Free except the documentation" JBoss and getting lost in the API set?
MORTAR COMBAT!
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?