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.
I know that you are probably looking for an open-source solution, but Sun has promised to release a free version of their application server this fall.
Sun "basic" application server
It will run on Linux.
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
don't get too cheap on the Intel HW, I mean quality hardware - no software runs well when the tin memory contacts get flaky or the fans seize up after a week. Use a percentage of sw saving for quality stuff and rest is punching buttons with minimal finger pointing at the resident screwdriver jocky & board swapper.The last production box we got even for Msft 2K server was just a 1.1Ghz P3 w/ PC133 ram, and 2 40Gb SCSI disks (low voltage differential, new one on me). Giving untrusted hw a weeks thrashing under simulated production conditions builds confidence immensely and avoids em-bareass-ment.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Apache is nice and fast for serving up static pages, and really nice with php pages.
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.
There are some odd things afoot now, in the Villa Straylight.
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
They don't put Anonymous Coward on the "byline" for nothing. A forum is designed to get information. The purpose of her post was to get some information from people who knew their head from a hole in another part of their anatomy.
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.
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.
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?
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.
They would once the bean counters come in....
Advanced users are users too!
UK local authorites, via the Accessible and Personalised Local Authority Websites.
This is a web toolkit based on the Arsdigita (of Phil Greenspun fame) Community system.
Their setup is *nix, Apache, Tomcat/Resin and Oracle.
Live today. Tomorrow will cost a lot more!
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 is okay, but I personally prefer Orion, 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.
Everybody dies.
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.
Compared to Orion and Resin, Tomcat also lost comprehensively. The arguments raged for a while over performance (for example)- 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.
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.
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.
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
the big question begging moving from a simple jsp/servlet engine like Tomcat/Jetty/Resin to a full blown J2EE app server like WebSphere/BEA/JBoss is Do you want to run EJBs?
... Tomcat is used by IBM WebSphere to run all the jsp and servlets in webSphere, which in turn can then utilize the EJBs...
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)
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
We're using Tomcat on servers here to replace PHP on Apache. Eventually we're going to phase out Apache and use just Tomcat. It works great except for one tiny thing for us, there's no equivelant to htaccess. Which makes setting up restricted parts of our website a tiny bit annoying. But once you get the hang of the xml config files it's pretty easy. As for robustness, one of the sites we run it on gets a few hundred thousand hits to the same 3 or 4 webapps. I think it's great. But I can't give out the company name.
Kintanon
Check out JoshJitsu.info for Brazilian Ji
I've got no experience with Resin and not too much with Tomcat. (I've used JRun and Websphere in the past and I like them both.) Anyways, there is a company at my local Java Users group that really speaks highly of Resin - I think this is the link.
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.)
Their position is that it will save them hardware costs to run on Intel machines instead of big IBM or Sun iron.
:-)
You mean AMD Athlon MP machines, right?
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 ;-)
Programming can be fun again. Film at 11.
I've heard good things that the Navy has been using Tomcats in production use for quite a while now. They even made a movie about it.
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.
http://trafac.chmcc.org
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).
Won't put our company name on here(it is a large UK health insurance company), but we use apache and tomcat for all our large scale web apps. For example we saved huge amounts of money by fronting our legacy middleware product with an app that you call using XMLRPC and it sits on Apache and tomcat on a Sun E10k domain. For performance it handles about 30 requests per second and about 1.2 million calls a day.
:)
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!
"Because we are not employing at entry level, offshoring will kill our industry stone dead."
At NetDoktor A/S we use Tomcat/Weblogic currently to run our Java platform. We're deseperatly trying to gain time to look at JBoss to see if we can kill off Weblogic.
/Ian
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 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 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
We are using JBoss and Tomcat in a production system, deployed in the government offices of 9 different governments.
For more information, see www.trackernet.org
Here are some good reasons to use Resin:
- Fast, reliable, scalable
- Easy configuration
- Full source code provided under a "Developer Source" license, 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.
Here's a testimonials and customer list 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.
Cisco is working towards moving all their web based applications to tomcat. Just about all their new applications are being written there.
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
That which does not kill me only makes me whinier
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!
with "servlet container" and-or "JSP container". both tomcat and jetty are fine examples of servlet and JSP containers.
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 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.
MORTAR COMBAT!
The problem seems to be that it is extremely difficult to benchmark such servers. Greg Wilkins, one of the primary authors of Jetty, explains the issues fairly clearly in a response to the Jetty Benchmark thread on the jetty-discuss list.
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). 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.
Signatures are a waste of bandwi (buffering...)
But just last week at our local Java users group James Duncan Davidson, the original developer of Tomcat (and Ant), and he really didn't recommend using Tomcat by itself in a large enterprise type setting where speed is an issue. He said using Apache to help serve up static pages/images will certainly help but it is important to keep in mind that Tomcat wasn't built for speed, it was built to be a reference platform.
On a side note Davidson is a good speaker and worth seeing if you get a chance to.
We may have been on a conference call a few weeks ago. Call it a hunch.
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.
+++ UGUCAUCGUAUUUCU
Anyone running Vignette's V/6 Enterprise Application Platform is running Jakarta Tomcat. It's a prerequisite. You can of course make custom connections to another servlet engine, but it isn't supported.
I don't have a customer list or anything, but there it is.
The Dopester
"Yes, I'm a Karma Whore, but I'm doing it to pay my way through school."
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
Well, you should check this site for JBoss support.
Or this 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.
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Maybe he's a bit rude, but I've never thought that Apache's configuration was a nightmare. Especially compared with another major free offering, which is configured with GUI boxes...
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.
Check out Computer Associate's portal product, CleverPath. 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.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
Ok guys, that's my experience. We had bad results with tomcat, our group of linux boxes (4 biprocessor pentium class machines RH 7.1) had big problems only with 60.000 pages on a day. What I appreciate less was the Tomcat ungraceful behaviour under stress. One moment all is Ok, after some seconds it starts trashing. We changed the code, installed Resin and achieve to serve 500.000 pages on a day with only 2 servers!!! Tomcat version was 3.2.something... Good luck!
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!
I was volunteered to evaluate application servers to replace what we had been using (New Atlanta's ServletExec).
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.
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.
haha your blood pressure doubled and pulse rate jumped 15 points, call it your exercise for the day.
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
Every application has different performance requirements and every app server has different pros and cons. It's absolutely critical that you figure out what you need from the app server.
Figure out and document the "typical" type of application you will need to run on your app server, then design and document an application architecture for it. Once you have the architecture, create a prototype of the architecture that establishes a "thin thread" through the entire architecture. For example, JSP to Servlet to EJB to JDBC. This is really important because one app server may be super fast at parsing and displaying a JSP but horrible at authorization checking. Now that you have the prototype, the fun part starts.
Conduct scalability testing, load testing, stress testing, and fault tolerance testing on each app server you are considering. Use your prototype architecture for the tests. Collect all the numbers and graph them out. It's really important that you establish a baseline hardware configuration and maintain that baseline throughout the tests so that you compare apples to apples.
This process is time consuming but I believe it's a critical. You will learn boat loads about each of the app servers as you do this. You'll learn what it takes to set them up, configure an application for them, how to administer them, oh yeah and also how they perform for your architecture.
Jetty has been developed mainly as an efficient HTTP/1.1 server. The Servlet container is secondary to providing correct and efficient service of the protocol.
Jetty has been focused on being embedable in your application, rather than being a stand alone application server. Hence it is widely deployed but with very low visability. I wrote jetty and I'm still surprized when I find the jetty.jar inside IBM tivolli or Sonic MQ!
What about TP monitors?
I have never been able to find a real free TP monitor.
I see everyone going nuts for application servers, but the fate of most of them is to suffer under high loads. I've never seen any of them incorporate the lessons learned by hard experience during 30 years in the TP monitor field.
This to me seems like the whole OO and Web fads: everything has to be OO and HTML and HTTP, and XML too. But few people learn the fundamentals. So they go and build beautiful applications on Java, HTML, MySQL, without ever realizing its unreliability or all the duplication of effort necessary. Or the risks for lack of scalability.
This is yet another thing the proprietary world gets not so bad as the free software world. For example, BEA's WebLogic Enterprise actually embeds the Tuxedo core to provide TP monitor services; they call it BEA Engine.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Tomcat is slower than Jetty in all cases that I've seen (I've not seen them all, so test it for yourself). Tomcat wants to be restarted everytime you deploy a new context(or I'm just stupid and don't know how to set it up right). Jetty is an embedded small fast implementation, that will run on it's own, but I recommend JBoss! With JBoss, you can create good war or ear files that you just drop in a directory to make things work. No hassle unless you can't write a simple deployment descripter and use jar, in which case you have bigger problems. If you think JBoss will use too much memory, you can just disable all most of it's services and it will be just fine. JBoss loads in anywhere from 7s (minimal services on fast machine) to 60s (all services on a ~400Mhz machine with 64+ M of ram, UDMA enabled on your hard drive, and IBM's JRE). Get a copy of JBoss and play with it. The only reason to run Tomcat is if you want to run Apache (because you like the way it does virtual hosts or you need PHP or modperl for some other project).
Java on Linux is a complicated thing to get good results from. You need a good VM, and the one's from Sun are getting better. I recommend that you take a look at IBM and JRockit as well and compare them for your own use. They are both have no cost, but are pretty fast. JRockit is pretty robust. I use the Sun VM now just because I need 1.4 features.
Karma Clown
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
In a commercial environment transaction volume
translates into revenue (or you have a broken
business model). If your transaction volume is
too high, buy another $%^@ box, dumbkopf!
By the way, your boss is obviously an idiot, so
I would suggest finding a new job ASAP.
-I like my women like I like my tea: green-
Try any of them. I use Resin. Others are happy with Tomcat. I've never heard of Jetty, but it may be good, too.
The important thing is that you write your application to the servlet spec. If you do that, switching servlet containers will be completely trivial. So if you later decide you've outgrown Tomcat, try something else instead.
You might want to try looking at the vendor pages at http://jakarta.apache.org/site/vendors.html
Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
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 just setup Tomcat and Resin to develop a Filter that exposes our library to containers. Results: Tomcat is pathetically slow compared to Resin. No contest.
We've found that we end up deploying the same applications multiple times, with restarts, in order to get the thing working correctly
Ugh. That should not happen at all - I'm working with news sites that redeploy and update several times a day on WebLogic.
The process is complicated, particularly in a centrally managed/clustered environment - your consultant needs to understand precisely what goes on so that servers don't accidentally share temporary directories, the component is targeted at the right thing etc. etc. It's a bit arcane, but not unreasonably so.
What's the central management console in JBoss? I didn't think it had one.
Use manual deployment? This is the standard recommendation for WebLogic environments.
Seems rather like you're cutting off your nose to spite your face.
simply because of an outdated association with the slow cgi stuff.
It's more than that. Even with mod_perl, you're still lacking the efficient thread support of a Java web app server - this really matters when your concurrency level starts rising and Apache starts running out of back-end processes.
And Java has a comprehensive security model, handles in-flight update and redeployment better, includes centralized management tools, has straightforward session and clustering support in many implementations, flexible and efficient database integration, not to mention a healthy market in applications and tools.
These are some of the reasons Perl loses out in big developments - it has some nice features of its own but these aren't generally considered as critical.
And servlet/JSP spec is part of what may I ask you? J2EE is a group of technologies and Servlets/JSP is one of them.
Your pizza just the way you ought to have it.
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
No they don't - check here.
What's much more interesting is that Linux on Intel (OK, and probably Wintel too) is the prime focus of BEA's own JRockit VM.
With Sun, IBM and BEA all investing heavily, the outlook for Java on Linux has never looked better.
We have used Tomcat in production since v. 3.2
4.0.4 is the only version I would really say is rock solid though, and we had puzzling cases where the CPU would go to 100% usage and stay there under earlier 4.0.x - this is under NT, so its probably bugs in the OS/Java implementation anyway. I never had this problem running Tomcat under Linux.
Overall, I have been very happy with Tomcat, whether integrated with Apache or standalone.
You might as well at least try Tomcat before a commercial Servlet engine, and you'll probably find there is simply no need to look anywhere else.
I gots ta ding a ding dang my dang a long ling long
PHP runs better. Faster response. Less overhead as far as CPU/memory usage. Greater availablity of code snippets on the web to shortcut deployment. PHP isn't just nuke. It's supported by a large company, and really works well. If you want to fully implement the features of Tomcat go with Zope. Even if you purchase Zope services from Zend Corp. you'll find that your return on your dollar is much, much higher. Especially since the load is lower on the server and as a result you can serve a greater number of users with the same box.
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
The company where I work just implemented Cardiff Software's Liquid Office online forms software, and it only runs on Tomcat. We've had some minor issues getting everything installed and getting Tomcat running, but once it's running, Tomcat has been fine. We've experienced no problems with Tomcat. We're running it on the same box as an IIS-based intranet, an IIS/MS-friendly content manager, and a web-based interface to our document imaging system.
The box I'm running all this on is a dual 933 MHz PIII box with 1.5GB of RAM and four 18GB 15K rpm HDs in a RAID 5 array, running Win2k Server. Performance is downright snappy. LiquidOffice is using LDAP-integration to authenticate users out ActiveDirectory, too.
Would I love to be running all this on Linux or Solaris or HP-UX or whatever, with some sort of high-quality LDAP-based directory instead of Win2k and ActiveDirectory? You're damn skippy I would. I hate Microsoft, but I have a lot of stuff I have to run that I don't get to choose and most of it doesn't yet run on anything except Microsoft.
I am very thankfull
I don't need to write haiku,
for topic reply.
The Kruger Dunning explains most post on
Well, it's pretty good actually, no need to put Apache in there just for that - it creates an access.log file just the same. Check the Server HTTP Logging help page. Only thing it doesn't do is merge the access logs for you across different servers in a cluster like it can do with normal logs - too much traffic I guess.
Filters appear in WebLogic 7 (they came in servlet 2.3 I think) - you write the class and then mention it in the web app deployment descriptor, e.g. using WebLogic Builder.
Maybe Jython could serve as a compromise, integrating the Java APIs with a better subset of Common Lisp
Jython is a Python on top of a Java Virtual Machine integrated into the Java libraries, not a CL.
However there are a lot of lisp implementations for the JVM.
see: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.h
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I have been trying to convice my large company to give OSS a chance (specifically CVS) but they want to talk to other large companies and get their take on it. What I need is a web site that contains a list of either references or quotes from large companies telling their OSS stories. If I could say that Sprint and IBM uses CVS extensively, and here is a inside contact that can talk about it, that would go a long way to opening the OSS door.
KangarooBox - We make IT simple!
Regarding Tomcat's role as a reference implementation: for HTML, XHTML, XSLT, MathML, etc., the W3C commissions Amaya as the reference implementation, but I don't see people giving up IE or Mozilla for the lastest Amaya builds...nor have I heard, "Yeah, but how does it look in Amaya?," when reviewing a new site design. So, not knowing the world of Java Servers, I find the repeated cry of "reference implementation" a bit weak as a recommendation.
-- @rjamestaylor on Ello
"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
My company began using it a few years ago as a replacement for a commercial JSP server that was a completely piece of crap. Compared to the commercial program it was okay, but it frequently (like once every couple of months) would lock up and require not only a complete restart, but in fact a "kill -9" of all java processes running as the Jakarta/Tomcat user.
Today we are using JDK 1.4 and Tomcat 3.x and are pretty happy. It doesn't lock up or do weird things anymore. Speed is okay; not blazing fast, but for our business, the compiling (or interpreting) of dynamic pages is not the slowdown. Database access is a hundred times as CPU intensive so speed of our dynamic content isn't really important. Our pages are fairly complex and usually compile in about 500ms.
All in all I vastly prefer coding web pages in PHP. Java is just plain clumsy for creating web content. But if you've got hundreds of thousands of lines of legacy code (like us), Tomcat will do you just fine.
Sure. I meant to imply that Python, as a language, is more "lispy" than Java, not that it is Common Lisp.
None of which seem to be CL, unfortunatly
Programming can be fun again. Film at 11.