Who is Using Tomcat or Jetty in Production? 488
"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."
Production Tomcat (Score:4, Informative)
Re:Production Tomcat (Score:3, Interesting)
My company uses tomcat exclusively (Score:5, Interesting)
Re:My company uses tomcat exclusively (Score:5, Interesting)
During load testing, we mucked about with the same tomcat parameters mentioned above, specifically thread count (starting and max) and heap size.
One last note: with versions 4.x of Tomcat, we've found that Tomcat is quick enough at serving up static content that we don't need to put Apache into the mix.
Re:My company uses tomcat exclusively (Score:4, Informative)
Remember, in 4.x, a command-line admin tool to insert/reload contexts at runtime has been added. A GUI is planned to follow.
Re:My company uses tomcat exclusively (Score:2)
Re:My company uses tomcat exclusively (Score:2)
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/m
Re:My company uses tomcat exclusively (Score:2)
Redeployment with WebLogic (Score:3, Informative)
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]
Re:My company uses tomcat exclusively (Score:2)
We can't use war files easily, because each build needs to be configured for the system on which it's being deployed. So we just deploy a pre-extracted tar file, with a configure script that substitutes in the appropriate values in various config files for the server in question.
Re:My company uses tomcat exclusively (Score:3, Informative)
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.
Re:My company uses tomcat exclusively (Score:2, Insightful)
And if you are not using Ant for builds, I would highly recommend you check it out. It's saves me so much time and, when I actually did have a job (a year ago), it saved my team and incredible amount of grief and time.
Novell (Score:5, Informative)
Re:Novell (Score:2)
JBoss (Score:4, Informative)
Re:JBoss (Score:2)
Re:JBoss (Score:2)
Everyone here should check the 3.x version, is one of the best software tools ever developed.
Re:JBoss (Score:3, Interesting)
I've worked with JBoss since before it was JBoss, and before it had any kind of support. I think it's fine as far as it goes, but your generalizations are not much more helpful than the original bit of flag-waving.
You appear to forget that some real customers are interested in things like usable security (not freeware Java SSL implementations), clustering that works with real hardware and centralized management for servers and applications.
These customers often also want to be in a position to handle future stuff like workflow and web services conveniently - not via 101 addons from different projects scattered around the web. This is what the Platform is giving them - the only competing strategy for this is from Microsoft.
If BEA were still selling 6.0 and had no coherent plan then you might have a point, but until JBoss has something that really is as comprehensive and functional there are going to be sufficient reasons for corporates to choose WebLogic.
I have shared your pain on the support side in the past (I've spent most of my time on the other side of the fence) but since the Web Support went live I've had no problem organizing things such as continuous, 24 hour attention to specific issues, with a problem being passed to engineers around the world in the middle of the night, and who I can talk to via one 800 number.
And for what it's worth, the BEA consultants I've worked with over here have been among the most clued up I've encountered from any organization. Unlike a lot of technology outfits offering consultancy, they tend to be old hands who can fix all kinds of stuff outside WebLogic - from routers to Solaris sys admin to Emacs init files - if the occasion demands. Sorry if your experience was different.
Free application server from Sun (Score:2, Interesting)
Sun "basic" application server [sun.com]
It will run on Linux.
Tomcat is bad but alternatives are even worse (Score:3, Informative)
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.
Re:Tomcat is bad but alternatives are even worse (Score:5, Informative)
Why? Tomcat can be used stand-alone and it can be integrated with other webservers, even IIS!
Re:Tomcat is bad but alternatives are even worse (Score:2, Insightful)
TUX! (Score:4, Informative)
You can read more about TUX here [redhat.com].
Re:TUX! (Score:3, Informative)
It works as advertised in that it's serving static content and very quickly. Tomcat serves the dynamic requests that TUX passes on to userland.
One caveat is that you have to use the HTTP 1.0 connector in Tomcat. I figured this out after almost a week of pulling my hair out. Since Tomcat uses HTTP 1.1 by default and HTTP 1.1 keeps connections alive to save socket negotiation time, it wasn't letting go of the socket and serving out 404s instead of letting TUX handle the next request. As time permits, I plan on tweaking the Tomcat code to disable keep-alives.
But other than that, it works just fine. Since Tomcat is handling dynamic requests which involve some processing time, the extra overhead associated with HTTP 1.0 is not an issue. We've load testing it with JMeter on a few hosts with no obvious problems -- but I'm sure that sending it live will uncover some hiccups (it always does).
Re:Tomcat is bad but alternatives are even worse (Score:2, Troll)
Sigh, its amazingly simple, just because you don't have a pretty GUI, does not make it a nightmare to configure, more to the point, there are many programs that offer GUI configuration of apache, have a look around before dismissing apache because you can't set it up right
I'm with the troll... (Score:2)
Re:Tomcat is bad but alternatives are even worse (Score:2)
Re:Tomcat is bad but alternatives are even worse (Score:3)
I'm confused. Is this a typo, or what? When people write "*nix" (an expression I really don't like, BTW), they're referring to all flavors and varieties of UNIX-like operating systems, including nominally non-UNIX OS's like Linux. So what do you mean by "Ja*a?" Is there a Jaba out there that I don't know about? Or a Jata, or a Jafa, or a Jaqa? What's the deal with the wildcard?
Re:Tomcat is bad but alternatives are even worse (Score:2, Insightful)
-ax
Re:Tomcat is bad but alternatives are even worse (Score:3, Informative)
Sometimes, one has to step back from the plethora of big-name projects and realize that people are making considerable effort righting the mistakes made by the early pioneers of that medium.
And sometimes, paying a little for a server engine ain't such a bad thing. Most companies with budgets can afford cheapo licenses.
How about Resin? (Score:2)
Obviously it's not open source which isn't exactly what you're looking for. On the other hand, what I hear is that it is fast, stable, and inexpensive. ($500 per deployed server.)
Re:Tomcat is bad but alternatives are even worse (Score:3, Insightful)
So the majority of webserver admins in the world are having a bad dream ?
Look, trying to use logic and something arguable to express your views is OK. But when you claim that the majority is stupid without any backing for your claims. It realy looks the other way.
Re:Tomcat is bad but alternatives are even worse (Score:2)
Jetty instead is a full-featured webserver with all the functionality built in. And now that its integrated in the JBoss 3.x series you can use JBoss instead and take advantage of the WAR deployment/redeployment.
You know, you can use JBoss and if you dont need the EJB, JMS, etc functionality you just disable it and create a custom configuration.
Use Resin if you care about performence (Score:4, Informative)
Re:Use Resin if you care about performence (Score:3, Informative)
Re:Tomcat is bad but alternatives are even worse (Score:2)
What "Configuration nightmare"?! Out of the box it'll run on a *nix machine (maybe Windows, but I've never tried it on a desktop OS). Really, there's just one well commented text file to edit, unless you intend to add user authentication to directories (which itself isn't difficult) - it's hardly brain surgery.
Now sendmail.cf on the other hand....
BEA is buggy as hell anyhow..... (Score:4, Informative)
Re:BEA is buggy as hell anyhow..... (Score:5, Informative)
6.0SP2 would not honor VariableInfo.NESTED in custom tag libraries
6.1 requires the weblogic.xml file in your WAR. Huh? Why in the WAR?
6.1 will hang for 30 seconds on your servlets if you open and close the stream without sending anything on the stream
6.1SP2 to set the proper application CLASSPATH
6.1SP3 fails to handle code that translates a SAX2 event stream to HTML using Xerces (SAX2) and Xalan (XSL); I'm dead in the water with this because our application depends on SAX2 streams
Honestly, I think I have spent more time tryiing to make WebLogic work than it took to write the application in the first place!
Re:BEA is buggy as hell anyhow..... (Score:2, Funny)
Re:BEA is buggy as hell anyhow..... (Score:3, Informative)
Yes, releases can be buggy - I never liked 6.0 - but after a couple of service packs it settles down. 6.1 is a fine J2EE 1.3 setup, and I like where 7.0 is heading, really pulls together all the complex bits.
On to specifics, if you're hitting memory leaks with the performance pack enabled, you are using some old version - no question! The only problems I've hit with the perf pack on current releases are to do with relatively obscure things like HTTP pipelining (the latter is a buggy spec if you want my opinion...). Turn on INFO level logging and check the report of java.library.path - you may be picking up an unintended version of the perf pack DLL/.so libs.
BTW Could be that now is exactly the wrong time moving an order management-type application from BEA to JBoss - WebLogic 7 has the Web Services and workflow management pulled together and when the Workshop tool caters for both (end of year?) constructing complex flows should be a breeze.
We use it (Score:2, Informative)
Is Tomcat crap? (Score:3, Informative)
"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)."
Re:Is Tomcat crap? (Score:2)
Since I like the development and production environment to be as much alike as possible, we also run tomcat for production (on an important 1000-user intranet application for a large bank). We run it stand alone to avoid problems with the connectors. I see no reason not to, since all our pages are dynamic so Apache would not bring any speed advantage, it would only be an extra relay/bottleneck between the servlet engine and the browser.
Re:Is Tomcat crap? (Score:4, Insightful)
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.
JBoss ! (Score:5, Informative)
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
JBoss == Tomcat (Score:3, Informative)
Re:JBoss == Tomcat (Score:3, Informative)
Just make sure it's good hardware (Score:2, Insightful)
Re:Just make sure it's good hardware (Score:2)
last time I used it, it was slooowwww (Score:2)
But in my own personal experience, and this was 2 years ago, Tomcat was really slow. It seemed to be just average with jsp pages, and then the more towards the j2ee route you went, the more worthless it was.
we were mainly using it as a quick and dirty testing/training server system, so I would assume that perhaps it has either come a long way since then, or it is only really meant to server jsp pages.
Tomcat (Score:4, Insightful)
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.
Choosing Tomcat over others (Score:5, Insightful)
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.
My company uses Tomcat + Apache + PostgreSQL.... (Score:3, Informative)
Tomcat is fine (Score:3, Informative)
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.
listen to his boss words (Score:5, Insightful)
he doesnt want to know what he can gain by using either of them, he wants to know he wont lose anything.
aplaws (Score:2)
This is a web toolkit based on the Arsdigita (of Phil Greenspun fame) Community system.
Their setup is *nix, Apache, Tomcat/Resin and Oracle.
Tomcat does suck, avoid it. (Score:3, Interesting)
Yes, I know it's free. Pay attention.
It does a relatively poor job of implementing the spec itself, and the spec is supposed to be its reason for being. It's gotten faster over time, which is nice, but it's still not very good at handling things. Tweaks abound, but running a custom version of a servlet container isn't likely to bring comfort to you... I hope.
I'd suggest spending some money on the container, myself; Jetty [mortbay.org] is okay, but I personally prefer Orion [orionserver.com], which is fully J2EE, fast as all get out, and very, very easy to administer. Installation of an Orion instance takes three steps: unzip, copy tools.jar, java -jar orion.jar. Done. It's also free for development, so there's no per-seat license cost for you to use it to write code.
An aside: Oracle recently posted ECPerf numbers which were very good, and Oracle licensed the Orion codebase... and Orion costs thousands less. Since ECperf yields numbers based on dollars per transaction, you'd think Orion would kick butt on ECPerf.
I find Tomcat to be acceptable only for compliance testing, because so many people think it's the best that out there (because of the price point). I've spent a lot of time having to work around Tomcat; I'd hope you didn't feel like doing the same.
Re:Tomcat does suck, avoid it. (Score:2)
Truth be told, I haven't seen many compatibility problems, though. Usually something that doesn't work on Tomcat doesn't work on Weblogic or WebSphere, either. If we do find a bug in the JSP engine, it usually is fixed quickly by the vendor (except, AHEM, in IBM's case, but I'll let bygones be bygones
Re:Tomcat does suck, avoid it. (Score:5, Insightful)
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 [sun.com] and Front page of Tomcat site [apache.org]. Thank you.
Comparisons, plus some opinions (Score:3, Interesting)
From my experience, Tomcat 4.x is faster than Apache and JServ.
Don't know how it compares to other servers (at least, from experience I don't), for example IIS, Resin, JRun etc.
Tomcat 3.x WAS very slow - for example, who had to combine Apache and Tomcat to get anything reasonable - using Tomcat for JSP and servlets, and Apache for static pages. This was in itself a bit of a nightmare. Tomcat 4 is miles better.
Comparing JRun to Tomcat for performance, see here [macromedia.com].
Compared to Orion and Resin, Tomcat also lost comprehensively [weblogs.com]. The arguments raged for a while over performance (for example [metronet.com])- but not many about whether it "did what it said on the tin".
A more serious point here is that your bosses care more about the name and image than the quality. I'd think about trying to convince them that this is Not A Good Idea. For someone who IS using Tomcat in production, just do a google search; you'll get quite a few, for example [eapps.com].
Not sure if this helps, but.... (Score:2)
I just installed the Jetty Web Server the other day so I don't have any real data to provide, sorry. I know of a few people that use it and have been happy with it. The only complaint that I've heard is that the pages take long to load. The person that said this thought it might have to do with the page being Java, but I think it might just be the database itself causing the slowdown. Just my $.02 worth.
weather.com is now exclusively Tomcat (Score:5, Informative)
For what we do, you can't beat the price... And yes, that includes the price of our time.
Rightworks used to use Tomcat.... (Score:2, Interesting)
Since the catalog server was a major piece of the procurement software, it had to perform. If people can't populate their cart, then what's the point? This software was sold to various 'largish' companies without any complaint on the performance of the catalog....
I'm not sure what they're using now, since I bailed just before the
If the performance isn't good enough, throw a few caching proxies in front of the web servers. You may want to do that regardless of what web server software you run in the back end...
Blogger (Score:3, Informative)
How I introduced free software into my big company (Score:3, Informative)
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
javaBeans vs EJBs (Score:2)
i'm not an expert on EJBs by any means, and i'm trying to ask this same question of my own projects, but what i keep hearing is this: EJBs allow me to run much more scalable than servlet/javabeans.
i dont know what your prospective usage numbers are, but if they are large scale (aka site on the internet that loads of people will hit hard) then you want to use an EJB architecture because you will be able to scale up with lots of big servers. given that you are working on PCs, my guess is that this is not the case.
Also, i keep hearing that utilizing an EJB App Server will bring with it database connection architectures like Container Managed Persistance etc. BUT... there are some great examples of utilizing other data access patterns like Data Access Objects (see the jpetstore example [ibatis.com])
i think it comes down to proper application architecture. make sure your applications have good design, and keep in mind scalability (especially with the data access bottleneck) and you should be ok.
oh yeah... in favor of tomcat
Tomcat in production (Score:2)
Kintanon
Running on Intel machines? (Score:2)
You mean AMD Athlon MP machines, right?
Navy (Score:3, Funny)
Watchfire's FeedbackXM is Tomcat-based (Score:2, Informative)
I work for Watchfire [watchfire.com] a leading maker of website quality management software. One part of the suite is FeedbackXM [watchfire.com], 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.
a production site using tomcat (Score:2)
It is a bioinformatics web site for finding promoters in DNA sequences.
I did not design it, I work on it though (use and develop it).
We are standardising on Apache and Tomcat (Score:2)
The reason for this combo? It works, we tried other products and they couldn't handle the load, and when you dig deep then the parts we were using were old versions of Apache and jserv or tomcat!
Not exclusively but want to (Score:2, Insightful)
So I'd like to stand forward and say, yes we use Tomcat, and yes it's been in production so long we'd never consider Weblogic as a JSP/Servlet container.
I run Tomcat in production (Score:3, Informative)
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.
Try Resin (Score:5, Interesting)
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
Re:Try Resin (Score:2, Informative)
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
Tomcat is at least 2 times slower than resin (Score:3, Informative)
My project is (Score:2)
For more information, see www.trackernet.org
Use Resin (Score:2)
Here are some good reasons to use Resin [caucho.com]:
- Fast, reliable, scalable
- Easy configuration
- Full source code provided under a "Developer Source" license [caucho.com], which makes it competitive with "free" products, at least from a commercial perspective
- Development use is free - no licences need to be purchased for development and testing purposes. Runs well on Linux as well as Windows; latter can be useful for test deployments on developer machines
- Inexpensive to deploy: $500 per server for the JSP version, $1000 for the EJB version; additional for priority support options.
- Commercial support - see their pricing page [caucho.com].
Here's a testimonials and customer list [caucho.com] which includes some pretty big names.Despite any appearances above, I'm not associated with Resin, except as a customer. I first heard about it here on Slashdot, a couple of years ago. We evaluated it and eventually switched a number of applications from both Tomcat and commercial servers and have never looked back.
Other servers that might be worth looking into are Orion and JBoss, but I don't know how they compare on some of the points above. The availability of commercial support from the vendor can be a clincher, and the source code provides some insurance against the vendor disappearing.
I agree with all the cautionary comments about Tomcat, although we haven't worked with it for some time now.
Tomcat is Cisco's preferred env. (Score:2)
Tomcat works for us. Regarding speed, if everybody says it's slow then maybe they're right. However, in my experience it's the database interaction that's slow, not the java code. Tuning the query can cut seconds, tuning the java cuts milliseconds. It's hard to fuss too much about the milliseconds when there is low hanging optimization fruit to be found in the sql.
Vanguard
Enough Tomcat Bashing... I have proof it works! (Score:3, Informative)
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 [ubeans.com]. 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 [jboss.org]!!! It rocks!
you're confusing "app server"... (Score:2)
an app server, i.e., a server which serves up J2EE applications, is more generally thought of as a combined servlet, JSP, and EJB container. BEA, IBM WebSphere, etc, and JBoss [jboss.org] are the real players in this space, but Oracle has their own app server rolling along now too. FYI, JBoss ships both a Jetty and Tomcat distribution.
Tomcat is the reference implementation for the Servlet and JSP container APIs. This means it is absolutely the standard. While Jetty is great for being "lighter" weight and more easily embedded, Tomcat would have to be my choice for "open source" servlet and JSP container.
Lack of good benchmarks makes it tough to decide (Score:2, Insightful)
The problem seems to be that it is extremely difficult to benchmark such servers. Greg Wilkins [mailto], one of the primary authors of Jetty [mortbay.com], explains the issues fairly clearly in a response [yahoo.com] to the Jetty Benchmark thread [yahoo.com] on the jetty-discuss list [yahoo.com].
In addition, experience shows that J2EE application optimization is not as straight forward as other Java applications, so it is easy to get radically different performance results from a servlet with only minor tweaks. There was a wonderful presenation at JavaOne 2002 San Francisco about servlet optimization (link for atendees only [sun.com]). Among other things, the author demonstrated. a simple 6 line "Hello World" servlet that is written in standard style, yet can be made to run 3x faster with only minor tweaks. He also shows that testing under load reveals that servlets can behave much differently under load and that the only way to really write fast and reliable servlets is to write them as you normally would and then test them mercilessly.
My conclusion is that you can't believe any of those published bechmarks, they're mostly biased marketting crap (everybody's benchmark seems to show their product is fastest). What you really need to do is load up multiple servers and configure them to do what you need them to do and test them under load to see how they perform in your environment. I know it's not what you want to hear, but since there are so many features that have varying performance, it's the only way to really find out.
A little name dropping here... (Score:2)
On a side note Davidson is a good speaker and worth seeing if you get a chance to.
Small World! We may have been on a conference (Score:2)
Here is my take...
I suspect you did a big cost analysis of the different Application servers out there. Looked at IBM, BEA, and a few of the other smaller players. Tomcat was listed, but written off. Things moving at the speed of business - the developers started building with Tomcat. Now there is lots of code and tweaking to Tomcat that may (may not) prove difficult to migrate. Additionally, it looks like your not going to worry about an EJB container for the first couple phases and focus on STRUTS instead.
Tomcat works great for development. It works amazingly well for fewer than 100 concurrent users - and that really works out to a lot of people. The cost factor is less of an issue. The full blown EJB container / CORBA ORB / kitchen sink tend to cost a pretty penny.... but a strait JSP / Servlet container do not. Weblogic Express goes for a couple grand - and contrary to what folks my say, you can get decent support from them. (Just make sure you are the contact rather than someone on the "business" side). I guess I view the cost as irrelevant at that point. Take the time to benchmark and load test on a production box (sparc?) a couple different solutions. . Some of the commercial Servlet engines are very fast - at the expense of some bleeding edge features you may get with Tomcat. Figure out if runtime or development time is more important.
That being said, yes... there are folks using Tomcat in production. I have seen tons of departmental stuff out there. Enterprise gets a little rougher - I've seen a few companies wedge it in.
Anyone running Vignette V/6 (Score:2)
I don't have a customer list or anything, but there it is.
Complementary (Score:5, Informative)
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.
Where is Tomcat used? (Score:2)
Check out Computer Associate's portal product, CleverPath [ca.com]. It uses Tomcat as its application server. My company is testing CleverPath right now for deployment as a B2B portal for our customers.
If I were you I would let somebody else do the heavy lifting on benchmarks, where it's in production, etc. Contact CA, tell them you are thinking about deploying their portal and you want to know where it's in production and what the benchmarks are. Since CleverPath can be deployed with a third party app server (BEA, WebSphere, Sun ONE) you need to specify a native deployment for the reference customers. Since you know that the app server architecture is built on Tomcat you will have good references for Tomcat that you can use to demonstrate its abilities, or lack thereof.
Tomcat in production sucks!! (alas!) (Score:2, Interesting)
See For Yourself... (Score:2)
The only caveats I have for you are to be sure that you use the groovy built in connection pooling for your DB resources, and that you tune your JSPs before going into production.
Good luck!
Jetty with JBoss (Score:2)
Jetty is very well integrated into the JBoss stack, and all calls between components are optimized, which is an attractive bonus for us.
Support for Jetty has been great on the lists. Very fast responses.
We used to use Tomcat, but it crumbled under heavy load. I hear these problems have been fixed, but I'm not going back.
http://www.liberationmedia.com
Same Position (Score:2)
Their main interest is in speed and scalability... and the $0 pricetag of Tomcat is also of interest to them (though not critical).
I've been testing Tomcat as well as Caucho Resin (www.caucho.com) and have found Resin to be much faster and feature rich, but my bosses are actually pushing for Tomcat because it's open source and free. I think mostly also do to the (hopefully) larger installed base so peer to peer support will be more of a reality.
BTW: Does anyone know a decent... free package that can script through a complex website (logins cookies, javascript) and load it down to test for performance? They want to see numbers of both of these and I have till friday!! eek.
Resin in a production environment, plus GLUE (Score:4, Interesting)
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.
.NET is the only way to go (Score:2, Funny)
JBoss/Jetty (Score:3, Informative)
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!
Re:Support? (Score:2)
That's fine, so long as they're aware that yelling is all they can expect to be able to do. Read the fine print in your support contract. You'll see that there's no guarantee to fix anything, and no liability if they don't fix it.
Re:Support? (Score:2)
Or this [mortbay.com] one if you want Jetty support.
The thing is, if your boss feels better having expensive support thay can have it, even as the same price of the commercial products. The win/win situation comes from the fact that expensive support is a may and not a must with free software.
Re:We don't get paid to do your job (Score:3, Insightful)
You obviously don't.
There are quite a few companies using Tomcat 4.0 or greater as a production JSP server and JBoss if they need EJB support.
However, there are faster web servers out there.
Resin and Jetty come to mind (use Google to find the Sites). Tomcat is a "reference" version of a JSP/Servlet Container. It is the first out of the gate... Others optimize stuff.
Tomcat 4.0 and above is scalable and clusterable, so you have the ability to do that, but so are several other open/source or less expensive Web Servers...
Check them out.
And idiots like the one above... If you can't be constructive.. Don't demonstrate your ignorance... just shut up.
Re:M... mu... mu wa ha ha ha ha. (Score:2)
Re:Get away from Java (Score:2)
However, for the type of work one would probably do with Tomcat, the point that there are a LOT of ready-to-use libraries for Java might me more important than the language itself - there just isn't as many CL code freely available.
Maybe Jython could serve as a compromise, integrating the Java APIs with a better subset of Common Lisp ;-)