Building a Stable and Clustered J2EE Environment? 43
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?"
WebObjects (Score:1, Informative)
Develop apps quickly
Provides a powerful integrated development environment
Allows you to create web services or three-tier Java server apps
Generates code-free prototypes in minutes
Build services dynamically
Allows you to create or use web services based on SOAP, XML and WSDL
Includes tools for code-free generation, configuration, and testing of web services from existing database assets
Integrates easily with
JBoss does this now (Score:5, Informative)
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.
Re:JBoss does this now (Score:3, Informative)
It took about 1 week for us to set up our cluster with hot deploy and session replication working properly, though I think the next time round it would be a lot quicker.
I don't think there are really any big issues in setting up a cluster though to set up a _good_ app server cluster you need to understand how the clustering implementation of your app server works and decide what is best for your solution.
Unfortunately there are
Re:JBoss does this now (Score:4, Insightful)
The problem is that they don't work.
check out Resin (Score:4, Informative)
Re:check out Resin (Score:2, Insightful)
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
Weblogic does this for us (Score:3, Interesting)
one tip (Score:2, Informative)
Re:one tip (Score:1)
Sorry, this is horribly off the mark in the general case. If you're talking about some particular software, you should be more precise. Someone following your "advice" (rated informative, no less, by an Esteemed Moderator) might be led to believe many doors were closed, when in fact the field is wide open. Use many little servers, or get a few "big iron" boxes, but, geez, pairing will demand a much larger investment in infrastructure and ongoing administrative effort than having, say, 6, or even 12 inst
Re:one tip (Score:2)
WebLogic only replicates state between pairs, never between three or more.
It's not necessary to understand the details of this as it happens automatically - essentially WL picks a secondary server that it knows is on a different physical machine.
If your BEA consultant has only ever set up a cluster once, and that for a version of the product dating from four years ago (I assume you mean WL 5.1) it sounds like he was an impostor.
Apart from these little criticisms, I have some sympathy with your "lo
"How To Scale" by Hardware Vendors (Score:3, Insightful)
"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)
Aren't these goals the rationale for EJB? (Score:4, Insightful)
Re:Aren't these goals the rationale for EJB? (Score:3, Informative)
incredibly easy (Score:4, Insightful)
Maybe this guy is trying to use the "Free except the documentation" JBoss and getting lost in the API set?
Re:incredibly easy - Oh yeh??? (Score:1)
Both of which 'cost and arm and a leg' for the documentation then rip you off totally when it comes to support.
Also the documentation on clustering for BES is very lightweight. YOu are looking at committing thousands to put together even the most basic clustered solution.
Will investigate your recommendations further though.
Re:incredibly easy - Oh yeh??? (Score:2)
I have heard great thing about these people (Score:1, Informative)
They create a SDK for creating appilcations that run over multiple systems and is extremly fault tolerant.
Clustering is hard, you can't avoid it (Score:5, Insightful)
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 [madbean.com]
Re:Clustering is hard, you can't avoid it (Score:2)
I have a question about that I've been wondering about for a while. How does the session know to replicate an object that's changing? For example, if during a request/response a mutator method is called on that object?
Say, for example, I have a Vector stored in the session. And each time a request is processed, something is added or removed from that Vector. If you never actually call set...() on the Session (just get the vector, t
Re:Clustering is hard, you can't avoid it (Score:2, Informative)
Yep, you've hit upon the clincher.
This is the problem. The session doesn't know, in this situation.
The only time a (key, object) pair in a session gets replicated is if Session.set...() has been called for that pair during this request/response cycle.
If you call a mutator on an object (where that object has been pulled out of the session), then that
Re:Clustering is hard, you can't avoid it (Score:2)
Hmm...
This seems impractical. You either lose your abstraction by having to make the session available to any part of the app which might change your object's state, or you lose efficiency by just having to assume that it's changed and force a 'set' every time it *might* have changed.
Perhaps the Java Servlet API needs to include another interface.
Check out this article by Bill Burke (Score:4, Informative)
http://www.onjava.com/lpt/a/1517
Cisco Load Balancing? (Score:2, Insightful)
Re:Cisco Load Balancing? (Score:1)
If you ignore the remaining layers of an N-tier architecture, then when a server/node goes down, your user session/transaction is...gone.
This is usually unacceptable to users. And thus to site owners.
I'm not saying implement "in y
Are EJB's really worth it? (Score:3, Interesting)
Excuse my ignorance, I'm just beginning to learn EJB. But as I learn more about them, I can't help thinking: "what's the deal?".
I mean, what's wrong with having your MVC webapp being based on JSP/Servlets, plus plain-old Java objects for the business-logic (accessing the DB via JDBC). Tomcat itself has support for load-balancing among several Tomcat servers; and as for the business-logic objects, these would be acting like client apps in a traditional C/S fashion, so they can be distributed without problems (and the transactional stuff should be taken care of by the DB, that's what RDBMS are for, no?)
So again, what's the big deal with EJB? Training wheels for programmers who don't grok databases and transactions; who think tha JDBC is too complicated??? Seriously, I'd like to be enlightened on this.
Re:Are EJB's really worth it? (Score:5, Interesting)
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.
Re:Are EJB's really worth it? (Score:4, Insightful)
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" [martinfowler.com] 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?
Re:Are EJB's really worth it? (Score:1)
Poster is dead on. At the risk of regurgitating that which has been opined upon so much in the past, EJB is not a high-performance solution. EJB is not a "load-balancing" solution, intrinsically. It is a bringing together of data/function --- and a way of making that data/function available "anywhere" (i.e., from multiple disparate data sources or processors, to multiple disparate dat
Re:Are EJB's really worth it? (Score:2)
When you get into other systems.. say a site like slashdot or similar, the forward caching that the EJB container gives you in a CMP world can bring a nice performance benefit to
Clustering on a Single Server (Score:1)
I'd second JBoss for clustering. The middle tier, EJBs and the like 'just works'.
The front end is tricker: e.g. setting up DNS round robin + virutal IP takeover in case a front end server goes down.
And the back end (database) is also fun. e.g. setting up a distributed file system. Or setting up database replication. Both doable, but hard to do right and get great performance.
I had one customer use our VPS servers to help them get clustering going.
They can set up several virtual servers (with the
Clustering todos -- (Score:1)
Thanks (Score:1)
I thought at this stage in J2EE development, clustering would be well understood and available 'out of the box'.
Thanks, Royles
Try Tangosol Coherence (Score:1)
If you are working with multiple servers, you should look at Coherence [tangosol.com].
We do a lot more than clustering app servers. Our product serves as an in-memory data store in a clustered application tier. If you have experience with high-scale J2EE applications, you'll probably have experienced what I call the "single point of bottleneck": the database. For some of our customers, we've reduced their database usage by 99.9%+ and their overall infrastructure costs by over half. With the replicated cache, each appl
do you really need all that -- n tier architecture (Score:1)
http://philip.greenspun.com/wtr/application-ser
cherio
venu