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.
We use Tomcat in production, as a replacement for JRun, which we used to use. It's working quite nicely.
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.
Tomcat 4.x series is designed and built for production use unlike the 3.x series which was a reference implementation donated by Sun.
Anyway if you're not doing EJB tomcat is a reasonable choice. If you ARE doing EJB work you can pick up JBoss which integrates well with Tomcat. Pick up GLUE for web services and a decent persistence layer (OJB for example) and you're all set for enterprise level development with $0 spent on infrastructure software.
Your pizza just the way you ought to have it.
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?
Go not to the Elves for counsel, for they will say both no and yes
"In conclusion, yes - in my book Tomcat is crap. I haven't actually really touched on the problems with Tomcat here (other than it has bad performance and bad developer productivity) and I apologise for that. Perhaps I'll get to them another day. For now, consider the other alternatives until Tomcat improves (which I hope - but doubt - it will)."
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
running on Linux for all our clients. We build and deploy customized web apps for our growing client list. We have been running Tomcat for more than a year, and its performance has been superb. Of course, our clients don't have high volume web sites. And we're not a large company.
Guns don't kill people -- people kill people.
But the guns seem to help a bit. (apologies to Eddie Izzard)
We use Tomcat pretty extensively over here (major league northeastern university). I have heard that Jetty and Resin are much faster. I have also heard TONS of praise for Resin (faster, easier to configure, deploy, etc.), so you might want to look into that.
That said, Tomcat is perfectly adequate. Unless you are running Ebay or Amazon.com or something, your main bottleneck will probably be your database IO. Typically Tomcat (and any servlet engine, in general) is set up with mod_jk hooked into Apache, so that Apache is the frontend that serves all static files, and *only* those paths which are servlet/jsp get forwarded to Tomcat. In the recent past there seems to have been some flakiness in the Apache->Tomcat connector, but I presume that has been solved by now. Also, until 4.x, the configuration file format, and class loading mechanism were changing each release, but I believe that has settled down.
Like many Apache (or maybe Open Source in general) projects you pay for not having the depth of features a commercial product would, but you get in return breadth of features, and the comfort of a de facto standard with tons of inertia and support behind it. Besides, the J2EE specs are written sufficiently well, that any servlet engine implementation is basically a dime a dozen. You won't lose with going with Tomcat - and you can always switch to a commercial product if/when you feel you need richer/deeper features (I know people who develop on Tomcat, but deploy on Resin).
I must still be naive because I still can't fathom the absolute craptacular $$$,000 amount companies spend on commodity software. Unless there is something you *really* need in a commercial product, it is usually not worth the hassle chaining yourself in.
It's 10 PM. Do you know if you're un-American?
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.
"If we need to deploy a new context, then restarting tomcat brings with it a 30-45 second outage."
Remember, in 4.x, a command-line admin tool to insert/reload contexts at runtime has been added. A GUI is planned to follow.
It's 10 PM. Do you know if you're un-American?
My former employer, a very large areospace company, was at one time very very much against any software that wasn't back by a "stable corporation".
... just in case it doesn't work out. Perform a cost/benefit analysis. Purchase a product if it's the right decision - don't let "free" blind you. Write white papers for management. Counter industry FUD "reports" ... as they're often BS that are easily attacked.
The excuse was that if something went wrong, my company could sue the pants off the software provider. Of course, they almost never did that - instead, they just wouldn't pay the bills until the provider complied with company demands.
Enter terminal emulator software. The popular 3270 emulator cost about $500+ per desktop. And with 10,000's of desktops, that was... um, expensive. So I started my own little cost/benefit analysis. We could buy a shareware product for $5 per seat, and it was very robust and served 99+% of the users (except for mainframe sysadmins, of course!).
And the savings was amazing. We rolled out the product slowly. Everyone was happy. In the end, everyone used the product.
This one little step put us on the road towards purchasing more shareware. Soon afterwards, we did the same kind of argument with freeware - and won.
Conclusion: Start with something simple that you can back away from
I work for Watchfire a leading maker of website quality management software. One part of the suite is FeedbackXM, a user feedback survey system (of the survey button on the web page / pop-up survey kind.)
FeedbackXM uses Tomcat as an application server. This information is in the customer documentation.
I would have no hesitation in recommending Tomcat for low and medium traffic sites; I don't really know enough to recommend it for very high traffic sites.
I'm old enough to remember when discussions on Slashdot were well informed.
I manage a few servers...
1 Apache box on an Ultra 5 (Slow sun box typically used as a workstation)
1 Tomcat box on an Ultra 5
I use mod_jk and hide the tomcat box behind the web server. This adds a nice layer of security and lets Apache process
In total I have 5 instances of Apache, ~100 instances of tomcat, and ~150 web sites. The apache box sustains about 2MB/s and about 400k/s gets sent to the Tomcat box to deal with. I have had very few problems with Tomcat 3.3.
If you need some redundancy I would recommend using the mod_jk load balancing. It works very well and is simple to setup.
My advice: Don't litsten to all the Slashdoters who gripe about anything to do with Java, give Tomcat a try. It works for me!
BTW: If you want to get into J2EE stuff, absolutly use JBoss!!! It rocks!
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
The servlet engine used in JBoss is Tomcat. Since he said he didn't need to do EJB (Servlets / JSP only) there is no value in using Tomcat with an EJB server added. That having been said, if I had to actually use EJB for something (shudder) I would use JBoss.
I am not a number! I am a man! And don't you
We can't use war files easily
Neither could we, but that's because the feature just doesn't work reliably.
A large number of times, you'd stick a new .war file there and it'd just ignore it. IN my opinion the only safe way to do this is:
- kill apache
- kill tomcat
- wait a few seconds
- kill -9 tomcat
- remove all of the un-jarred directory ~tomcat/webapps/whatever
- start tomcat
- wait about 10 seconds
- start apache
If you're feeling daring, or are using the webserver for other sites, don't kill apache in step 1, and just restart apache at the end. mod_webapp seems substantially less resiliant than mod_jk at restarting - with mod_jk you could just leave apache alone completely.If you don't wait about 10 seconds between restarting tomcat and restarting apache, you run the risk of mod_webapp failing to connect to tomcat at all.
If you don't delete the appropriate webapp directory, in my experience your .war file is never actually unpacked.
I agree about Resin. We run it exclusively on our production machines.
It is "sort-of" open source, you can see the code, make changes, just not redistribute it. The makers of resin (caucho.com) are very good about taking good code, though...
Development licence is free, and production licence is $500 / server.
Resin blows both webLogic and tomcat out of the water.
_Am
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.
Posting anonymously because I modded this thread.
h ared/lib
Epesh hit it on the head. Tomcat blows. The classloader is totally fnarkled from 4.0.3 to 4.1.3 and possibly later since I haven't seen it addressed at all. It's supposed to load classes from:
WEB-INF/classes
WEB-INF/lib
shared/classes
s
common/classes
common/lib
in that order. I may have shared and common reversed, but that's not relevent to make my point. Try putting log4j.jar in your WEB-INF/lib. Oops, now Tomat cannot find the XML-RPC servlet in jaxrpc-ri.jar in common/lib. Huh? I don't know either. Try putting log4j.jar in common/lib and now your web-app can't find log4j.jar at all. The point is, if you try to load your own copy of something tomcat already has (especially anything having to do with XML), the classloader takes a crap on your application.
And often you cannot rely on Tomcat's included jar especially if you want to use a new feature. Resin doesn't seem to have this problem (nor Orion).
I honestly don't know how Tomcat became the RI from Sun. Resin is much better. I develop on Resin, then try to run on Tomcat. If Tomcat can't run it, I figure it's a Tomcat bug - and I'm usually right.
-joeblowgt
I've been working for a company a while now that uses Tomcat as it's sole application server, and it runs fine for us. Just a handful of servers provide for hundreds of users without a hickup. We are advantaged to have very good developers, which is the key to any application server.
No matter what application server is, BEA, NAS, ASP, ColdFusion, Tomcat, Jakarta, it all depends on how the code is deployed. Bad code makes or breaks performance. What kind of platform the code runs on has much less to do with performance than what kind of code.
I've seen ASP zoom and I've seen ASP choke on 11 users. The difference was not that they ran on Microsoft (although it's always fun to jab them), but rather the developers who used horrible routines and memory management, and created a monster that couldn't sustain more than 11 connections.
BEA lists the IBM JDK as their platform requirements for the Linux platform. We found that Tomcat 3.3.1 / IBM 1.3.1 would serve around 1.2 million page views a day on a dual proc Linux machine.
I don't care what anyone says, this is definately ready for prime time, and in fact was faster than BEA WLS5.1 running on E420Rs.
"The similarities of sysadmins and drug dealers: both measure stuff in K's, and both have users."
We just finished some benchmarking on our internal app-server. we found that tomcat ran 2-4 times slower than BEA/resin. Before we knew about resin, the cost of buying the extra hardware for tomcat was greater than paying for the extra BEA licences. That said.. we found resin, it is just as fast as BEA in our tests, and we are looking at using it and saving some $$$
We use tomcat exclusively. We have tried a few others but we have settled on tomcat. First reason is that when the project was kicked off, tomcat was free and it allowed us to trial the technology. Tomcat proved usable in the development environment and did what the development / design team wanted. As it got nearer deployment time a decision was taken that we had timescales to work to and all of the testing had been done with the webapp running under tomcat. We have since been using it in a live environment for nearly 12 months and (currently) have no problems with it. We use both tomcat 3 and 4. We had a few teething trouble to start with but that was more down to our lack of experience in general with running a java web server. One of the major beneifts I see in using tomcat specifically and open source stuff in general is support and product information. Although commerical companies give you a number to call if stuff goes wrong with their product, freely available information on the net is less prevalent. So you are dependant on the number of people available in their support department and the skill of the tech support you speak to. The likelyhood of you doing something brand new that has never been done before is remote. What is more likely is that you are trying to do something that isn't in the install docs but many other people do. And where open source works better is that you are much more likely to find help on the internet to boost your understanding and resolve your problem. This will make your able to respond to your businesses requirements quicker and more confidently. The other thing that commercial products tend to offer is "pretty" GUI's for configuring software. Aside from the support, this is the only thing that a commercial product will offer you that tomcat won't (same thing with apache vs. zeus). Now that is up to you really. Personally I think that as long you should get an understanding of how to configure tomcat then that isn't really a problem. I would personally have no qualms about recommending tomcat to anyone.
The Romans didn't find algebra very challenging, because X was always 10
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.
We've been porting an app from SilverStream (complete pos!) to JBoss. Originally we used JBoss/Tomcat, but have moved to JBoss/Jetty since the Jetty guys have been much better at supporting features via JBoss.
;-) Never thought I'd see the day ;-)
I would recommend against straight servlet/JSP development. Using EJBs, you get portability to different user interfaces, data source pooling, transactional integrety, and a larger choice of security options a la JAAS.
Since we're working on JBoss, I can write message beans for JMS systems, I have a built in timer mechanism, I can hot deploy by copying my ear file to a directory.
I can federate enterprise wide Directory Servers (LDAP via JNDI) and Databases, integrate with MessageQueue systems (MQSeries), tie in with CORBA apps and manage everything via custom JMX apps.
Jetty was also easier to work with in the development cycle, we didn't want to unpack the ear and war and redeploy the EJBs every time we changed a single HTML tag in a JSP, so I wrote an Ant target that copies the JSPs and associated stuff to the Jetty temp dir where Jetty does a great job of finding it and recompiling it.
Tomcat's temp dir structure was too dynamic and unpredictable to do this. I've also found more options when configuring Jetty via JBoss than Tomcat (you don't use the std config xmls, they have JBoss specific ones that JBoss parses and passes on to the Web Container).
The other beautiful thing about JBoss is the JMX. JBoss is really a JMX 'spine' with the EJB Container and Servlet Container (Jetty or Tomcat) as interchangable JMX MBeans. You can provide your app way more in the way of services.
Also Jetty supports clustering, real session clustering in JBoss.
JBoss has also integrated Apache AXIS so you can expose your EJBs via SOAP if needed. (I still hate SOAP though) Using EJBs I retain the flexibility of my user interface, since the data model and business logic are in EJBs, I can write a GUI client with relative ease, or expose my EJBs to a CORBA client via JacORB (also integrated with the default JBoss install).
Some things to also look at if choosing the J2EE path:
Apache Struts or Jade for web user interface development
Xdoclet for generating your EJBs and maintaining all those XML files in your source code (web.xml, jboss.xml, struts-config.xml, ejb-jar.xml, etc.)
Ant, become one with Ant, you'll thank yourself later.
http://sf.net/projects/middlegen
Middlegen, point app at database, generate CMP Entity Beans and basic CRUD ops in struts, write business logic, then user interface, done with new J2EE app.
ArgoUML and UML2EJB
Create a UML diagram, generate EJB code. Still a work in progress, but very promising.
With all the development in code generation tools, I'm in danger of becoming a point and click programmer on Linux
Downsides, XDoclet and Middlegen are lacking in docs, Ant has a lot of useful, poorly documented tricks, JBoss could use some more docs too, or at least better organized ones... (I even have the subscription docs)
Believe me, get into the J2EE swing with all the loving Open Source tool goodness, you'll never want to touch Perl or PHP again. It just works so much nicer, and the pace of development is blinding fast. Also most of the J2EE open source projects deliver, and deliver on time.
The community is great. Mailing lists are good, IRC not as good. Sites like The ServerSide and JavaLobby have a lot of good info as well and their forums are really lively.
With JBoss and the other open source tools it's the feel of a well supported commercial environment with all the source goodness you can read, and it scales up to enterprise class systems and development methodologies, try that with Perl/PHP!
Arrogance is Confidence which lacks integrity. -- me
The prospect of restarting the whole server just to update some JSPs or to redeploy a web app is, frankly, a complete non-starter for most large sites.
A lot of WebLogic shops update their content regularly, often using separate content management systems like Vignette (I know...), so if the original enquirer has requirements like this then Tomcat can be ruled out right now.
To wax on WebLogic's virtues a bit (hey, gotta restore some balance!) it allows you to redeploy a whole WAR (as a single file or as individual ones in 'exploded' format), to update JSPs automatically just by writing them to the source directory, and to update other servlets using the refresh tool.
[Disclaimer: poster is an independent BEA consultant type]
I've got just one datapoint:
We were deploying a commercial application which was shopped by the vendor with Tomcat. As this is the way the app was installed by the vendor we counted on running that way in production.
In the weeks before the official production started we were hosting the classes for the future users. This was the first time we had more than the three developers online at the same time and it failed miserably. We had to restart tomcat every 45 minutes !
As I had previous good experience with Websphere we decided to switch over and this solved our stability problem at once. The first three months it just kept going without any intervention. In the meantime I've added preemptive weekly restart to cron to be on the safe side.
For our environment Tomcat (V3.x & V4.x, I've tried several incarnations) was not stable enough for production. I'm still a bit stumped about this, the app was shipped with Tomcat by the vendor. This might have to do with the hardware (IBM pSeries), I don't now.
Markus
"Apache now ships as the default web server for NetWare 6, so Novell shops: Take note. A patch is available from Apache [apache.org], and Luigi describes a workaround in his article."
But Apache 1.3 is the default version that ships with NetWare 6, not Apache 2.0