Slashdot Mirror
Who is Using Tomcat or Jetty in Production?
"These are all excellent signs. The next step is to get an open source server into production. Tomcat is the natural choice because it's got the name recognition among Java app servers. Here's where I'm a little stumped. Whenever I mention the words 'Tomcat' and 'production' together, performance junkies come out of the woodwork and tell me that Tomcat sucks for production (what with it being a reference implementation and not optimized for speed). They say use Jetty (except for the ones that say to use Resin). The counter argument is that if my managers have heard of Tomcat, and seen vendors that will support Tomcat, and have never heard of Jetty, then there's no way they're going to bless it over Tomcat. (The same boss who praised Tomcat above also made a face when I mentioned JBoss. And I'm sure it has nothing to do with his personal experience with either.)
My question is, does anybody have some real world numbers of large institutions actually using these servers in a production environment? If somebody can tell me 'Company X uses Tomcat exclusively' then we would have no problem contacting company X and saying, 'So, what have your experiences been?' In other words I need leads, not actual white papers (although those would be nice, too). I need some real experiences, not just people who like Jetty over Tomcat because they don't like Sun."
Can't give our company name but we're using it in production for an ASP-type senario serving apps to large financial institutions off of WinNT boxes. Compared to the previous IIS builds (ugh) it's wonderful, stable and a nice advert for taking the whole show over to UNIX.
Like the subject says. It seems to work OK for us. Startup times are annoyingly slow. If we need to deploy a new context, then restarting tomcat brings with it a 30-45 second outage. But other than that, it's fine. Performance testing showed that increasing the number of threads the connectors can handle, and increasing the memory size (we use -Xmx500M) helps enormously.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Novell's Groupwise version 6 runs on Tomcat with Apache. It's actually set up to run on Netware, of course, but I've gotten it running quite nicely on linux as well.
"Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
Take a look at JBoss, we replaced BEA with it for commercial product deploys and have been thrilled. It can also be integrated with Tomcat or Jetty.
We use a BEA app server at work for our order processing system. Generally it works ok, but serious bugs in it cause us a lot of greif and downtime. First off it has serious memory leaks in the performance pack (trading speed for stability). We have to boot the BEA app server at least once a week least it runs out of memory and crashes. We are currently looking at JBOSS as our new production application server due to it's stability. If you code smartly you can move the code back and forth so you really have nothing to loose....
Got Code?
JBoss is an excellent fullfledged J2EE application server.
:)
They even offer consultancy if you cannot get it right the first time.
Excellent award winning server, excellent support, what do you need more ?
It has Jetty integrated and gives you the full J2EE stack.
You can get it to work with Tomcat too: no problem.
Check it out, the design is awesome for the techies.
The support option is great for the management.
Everyone's happy
We've been using Tomcat in a production environment for 1 1/2 years and before that we were using Tomcat's predicessor JServ. It's been rock solid. 4.0 brought a lot of nice changes (like not overwriting the logs on startup!) and 4.1 is a refactoring release for performance. The one thing to keep in mind about Tomcat is that you have to write your own wrapper script/program to make Tomcat start up as a non-root user. If you're going to use it in conjunction with Apache, Apache2 will only work properly with the ajp13 connector. The webapp/warp connector doesn't seem to work properly yet.
If you're going to replace BEA though, consider looking at JBoss which is a true J2EE server unlike Tomcat which is just a servlet container. To replace a commercial product such as Weblogic, WebSphere or iPlanet, you want to look at JBoss for a complete J2EE/EJB solution.
Some people take their .sig way too seriously
I come from a similar situation and have managed to do what you want to do. To sound a little zen don't try to change their minds just show them the benefits. In my case I drew on my knowledge on the lack of vendor lock-in combined with the economics of the situation and the inclusion of support in our seperate support contract (really cheap support at that).
As for support that was never really and issue with us so I have no argument there. Now Tomcat has some flaws (most in the JSP compiler Jasper and their live redeploy area), but is otherwise a very sweet little servlet engine (don't call it an appserver it isn't one in the J2EE sense of the word and that is the game you're playing when you use things like servlets).
Once it has compiled your JSPs it works just fine and the sweet things and the selling argument for our projects was redundancy of providers. You have a change of enviroments like going to another servlet engine. With a very minimal amount of care in your coding and everything is portable in fact if you stick to the Servlet/JSP api then you're good to go.
In fact we had some time one evening and switched between Tomcat, Resin and Jetty with only a few minutes spent making the configurations fit and the files unpack and install.
On a sidenote if you can delay any lock-in on a specific version of Tomcat, try and see if you can get your system over on the upcoming Tomcat 4.1 I am loving the improvements it brings esspecially in speed.
You should try to change his opinion on jBoss though. jBoss has been the most loved thing about that recent projects (and EJB writing is in combination with a good Ant script and XDoclet http://xdoclet.sourceforge.net not that big a pain). It is probably the most stable thing about this entire project with hot redeploy (great for development), good performance and great ease of use and install on top. In fact the new 3.x version is even greater with clustering, failover and some very interesting innovations in the area of control over which parts of the server to actually run via SARs and JMX. But enough about all this.
Having said that, Tomcat on the back end means Apache on the web tier
Why? Tomcat can be used stand-alone and it can be integrated with other webservers, even IIS!
to tune your answers.
he doesnt want to know what he can gain by using either of them, he wants to know he wont lose anything.
We have migrated to Linux, Apache, and Tomcat over the last year-and-a-half. We use it both in development and in production, across 100 or so boxes. As with everything, there are issues, but for the most part we are very happy. Even most commercial vendor's idea of a "big" site doesn't come close to what we do, so we have found very little difference between problem solving in the open-source and closed-source worlds.
For what we do, you can't beat the price... And yes, that includes the price of our time.
I run two production Servlet Containers. One is Tomcat 4.X, the other is on Resin. While Resin is not open source, the cost is only $500/server, which is quite low by J2EE standards. I believe it is free for development, but I could be wrong.
I tried Resin since I have heard "buzz" about it in message forums, and now can't say enough about it myself. Tomcat has a lot of quirks with reloading updated war files, reloading modified JSP's, etc. Resin does not have these problems, and I believe is much better suited for a non-stop production envirnment.
In Tomcat, it is not uncommon for me to have to restart the container when rolling out updates where certain things have changed. In Resin, I can even add or remove a JDBC Connection Pool from the resin.conf file and have to pool rolled out or back without any additional intervention from me. In short, it just works. Not only does it work well as far a few (if any) glitches, it is VERY fast as well.
For a commercial envirnment, I suggest you try Resin just to see if you find the value it adds over Tomcat worth it for you. I did.
-Pete
Soccer Goal Plans
What the hell are you talking about?
You didn't mention what spec you mean but I think you meant that Tomcat implements Servlet, JSP etc. specs poorly?
I wonder what is your standard for poor but you can't get any better compliance than what you get with Tomcat namely it happens to be the official, Sub-blessed reference implementation of these very specs. If you're in doubt, then check these URLs: Java Servlet technology - Implementations ja Specifications at java.sun.com and Front page of Tomcat site. Thank you.
Resin is significantly faster than tomcat. Catalina (Tomcat 4.x) has close the gap somewhat but if they still have a long way to go. OTOH, if cheap / stable is all you need then Catalina is a great way to go. FYI, Resin comes with all the source but is not free. Any of the EJB server will be total overkill and the overhead will soak you. And Websphere (at least the servlet side) is based on Tomcat (as is JBoss).
I am not a number! I am a man! And don't you
There seems to be a lot of confusion about what Tomcat, Jetty, JBoss and J2ee App-Servers. They are not really competative but complementary products. A Java AppServer is composed of [at least] three main components. The HTTP deamon, a Servlet/JSP container and a EJB Container.
Jetty is a primarily HTTP deamon, it is designed to handle HTTP request in a scalable manner.
Tomcat is a Servlet/JSP container, it implements the Servlet API it provides limited HTTP handling and no EJB support. Tomcat is highly reliable more so than most commercial 'industrial strength' App Servers. On the performance side; the Tomcat 3.x architecture is not hot but is adequate for many applications, all but the heaviest loads. Tomcat 4.x is significant better in this regard, because it includes an enhanced HTTP deamon.
JBoss is an EJB container which uses Tomcat 4.0 as it's HTTP deamon and Servlet container.
We've tested both Tomcat and Resin, and decided to go with Resin for several reasons.
.Net to shame, and it's way easier than offerings from IBM, Sun, Bea, Borland, or the Apache/Tomcat efforts. It's so easy to use that already you can make your *existing* applications be Web-Services compliant without re-writing or re-compiling them!!! You just tell GLUE which classes and methods will be exposed as Web Services and it automatically generates WSDL and starts listening for SOAP clients!!!
First of all it is very stable and very fast. And secondly, it has a very comprehensive way to do clustering, fail-over, and distributed sessions management.
In just a couple of minutes you can set it up to cluster with several copies of Resin, each residing on a separate machine, on the same machine, or even in the same VM. You can even set up a Resin container to be a backup of another Resin container in the same machine, so you get both inter-machine and intra-machine failover.
You can also do distributed sessions in several ways (with TCP messages, database storage, etc), and you can even force a user session to stay within the same Resin container out of a clustered group.
As for Web Services, we heartly recommend GLUE from The Mind Electric. It's bar-none the absolute best (in terms of speed, stability, and easy of use) Web Services toolkit available for ANY platform. It puts Microsoft's
As for a database, try the latest non-beta version of mySQL. It supports row-level locking, full transactional support using innoDB, and it is fast (specially considering its price). (Note that postgress is also a good alternative).
Note that like many here, I also agree that Tomcat and JBoss are great solutions to your needs, so if your boss definitelly cannot be convinced otherwise, I think you'll be fine with Tomcat at least. I only advice you to design your applications in a way that they can cluster, so that you can increase performance easily by adding more Tomcat servers to the mix.
If speed your concern for static content, put TUX in front of tomcat. No config changes are necessary for tomcat and TUX can saturate gigabit ethernet adapters easily and with comparatively little CPU overhead (more CPU free for tomcat to handle the dynamic stuff).
You can read more about TUX here.
- I don't need to go outside, my CRT tan'll do me just fine.
I can't help but think that this article is just poorly written. It doesn't really paint a clear picture of what he's using Tomcat for. He mentions nothing about the various configurations tested. It's way too easy to just write him off due to an overly evident bias against Tomcat from the beginning. (Hint: when attempting to persuade people, calling a benchmark test "Is Tomcat Crap?" reveals your bias...)
I use Tomcat at work as the development platform we use. We're probably going to be using Oracle Portal for the production system (not that I know what that is or what it uses for it's JSP engine, but...). It works fine for a development platform.
I haven't done any performance testing on it (yet), but when I get the chance, I might look into it. It'd be interesting to find out what my results are. I have a suspicision that Tomcat performed poorly in his "tests" because the other servlet engines came in an optimized for speed setting while Tomcat comes "optimized" for development.
You are in a maze of twisty little relative jumps, all alike.