1 comment so far
Since I have been in the middleware field, I’ve been visiting lots of customers. And a very high percentage of them are using a very similar setup for their web deployments: an Apache httpd front-end acting as a long-balancer/failover for a cluster of tomcat-related instances (“-related” since it can be any flavor of a tomcat-engine, including JBoss AS).
But each time I met with any of those users, the problem is ALWAYS the same: which load-balancing module should I be running in httpd? mod_jk? mod_jk2? mod_proxy? which version? in which setup? For which OS? Truth is that picking up the right module isn’t exactly an easy choice: all had their own little issues, shortcomings and some releases would simply not work reliably on some OSes.
At JBoss, we had decided to fix the reliability issues by providing stable releases of those mod_xxx compiled on many different OSes. Still, this wasn’t fixing the fact that none of those modules provide enough features for a sophisticated load-balancing/failover setup. Consequently, about 1-2 years ago, we initiated a new project aiming at providing a clean next-gen solution: mod_cluster.
From the mod_cluster overview page:
mod_cluster is an httpd-based load balancer. Like mod_jk and mod_proxy, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes. Unlike mod_jk and mod_proxy, mod_cluster leverages an additional connection between the application server nodes and httpd. The application server nodes use this connection to transmit server-side load balance factors and lifecycle events back to httpd via a custom set of HTTP methods, affectionately called the Mod-Cluster Management Protocol (MCMP). This additional feedback channel allows mod_cluster to offer a level of intelligence and granularity not found in other load balancing solutions.
The good news is that mod_cluster recently hit the 1.0GA milestone.
So, using Apache as a front-end to your JBoss or Tomcat worker nodes? Check-out mod_cluster, I bet this will quickly become part of your deployment.
So, what’s up JBoss? June 8, 2009Posted by Sacha in /dev/null, IT, JBoss.
1 comment so far
For the last 8 years, JavaOne has been an important time in the year. A lot of product activity would focus on this deadline. Except for this year actually: I realized JavaOne was over just 48h ago…Well, I had a good excuse as I was extensively working on a new framework. No worries, I am not working on a new ORM or web presentation layer, but helping a friend on some “real stuff”:
So, I did a quick check of the recent JBoss announcement and discovered the “JBoss Open Choice” tagline, which included several announcements.
The most important ones were about the split of the good old JBoss AS in three distinct cuts:
- Full EE profile (with IIOP, full JTS support, etc.)
- Web profile (similar to the future EE6 profile but applied to EE5)
- Simple Web server – this is really Apache httpd and Tomcat and a bunch of mod_xxx Apache modules but available for multiple OS – not only RHEL
Engineering wise, they are mostly cuts at the same codebase (which is great QE – and patch- wise – less cost) but from a business standpoint, it offers more flexibility to the user. You can see this as the first axis of a two-axis grid.
Then, on the second axis, Red Hat now supports a bunch of frameworks typically used in enterprise applications such as Struts and Spring.
As a result of these two axis, these frameworks are available à la carte on all of the runtime cuts. I like this a lot.
As a reaction to this announcement, Rod Johnson from SpringSource posted a lengthy reply explaining how RHT was reacting to SpringSource’s leadership… A few notes are in order:
- JBoss has had a flexible architecture allowing all kind of setup (from a simple embedded micro-kernel) to a full fledge certified EE5 application server since 2001 – so the “tc” architecture if anything is just 7 years late (tc was released last year)
- The various AS cuts are here to make customer work easier and provide various price tag – SS didn’t invent the notion of a “small server”, actually they can only be a “small server” since they lack the other pieces required to be anything else.
- “SpringSource leadership blablabla”… Yes, congratulations on the Open Source Spring framework, it now catches on the popularity of Struts, so RHT should definitively try to make money on it – still I fail to see how this translates in any particular SS’s leadership? Is that a revenue/booking metric? number of tc-server customers? Spring != SpringSource.
- Tomcat and its suburbs is what it is today thanks to the work of the Tomcat community, including the amazing work done in the last 6 years by people like Rémy Maucherat, Jean-Frédéric Clere and Mladen Turk – all RHT employees. It seems that SS is fast to hijack laurels.
Truth is that I just don’t think the market needs a new runtime – especially if it doesn’t add any meaningful feature:
So, is this a “reactive move”? Yeah, possibly, even though I would more accurately call it an “opportunistic move”. I am glad RHT is agile enough to lead in so many ways but yet, jump on side opportunities when they make sense. Not doing so would be a puerile and misplaced sense of pride: 4 or 5 years ago, if BEA had properly reacted to the JBoss threat, I am not sure JBoss would have become what it is today.