On 2/28/06, Tomasz Nowak <[EMAIL PROTECTED]> wrote: > > Tim Lucia <[EMAIL PROTECTED]> wrote: > > > > Send Tomcat a QUIT (11) signal on Unix, or control/break (run it > > interactively) on Windows. This will cause the VM to dump all thread > > stacks. > > > > If you don't like Tomcat, you can always shell out some big bugs for a > > commercial application server. For some even bigger bucks you can get > > commercial support. I can tell you it's unlikely you'll get a warm > > reception from the very people who can help you given the current > > tone of your postings. > > Your right, the tone of my postings is inproper. > I've been using 'free' software for almost 10 years now > and I pretty well get the rules. My only excuse is the > level of my frustration, based on recent Tomcat use. > > For now, the only contribition to Tomcat community > I can give is _pointing_out_ some real-world problems, > that typical users of Tomcat may face (and face!). > The problems are: > > 1. Poor/none default logging facility in 5.5.x. > - no real help/tips on error sources > - no examples how to do a decent virtual hosts logging > - no tips how to switch off a lot of uneccesary trash log inputs > If Tomcat is supposed to be production ready why > it has no production ready logging features?
I think if you take the time to compare Tomcat to other servers like weblogic, websphere and jboss, tomcat's logging is comparable. 2. No real-world, step-by-step docs how to TRACE and eliminate > application errors that lead to server failure. That is > probably a problem lot of Tomcat users must struggle with. honestly, besides Weblogic, most servlet and ejb containers do not provide simple and clear instructions for tracing issues. With websphere, you have to buy an expensive license of WASD and even then debugging an issue won't be better in my experience. Debugging an webapp is a difficult task and very time consuming. I sympathize with you, but the only real way to trace is to use a profiler like optimizeIt, jprofiler or yourkit. An alternative would be to run tomcat with Sun's JFluid VM which is experimental. 3. During last years I see no actions taken by Tomcat dev team > to eliminate Tomcat server failures caused by webaplications. > Is it really impossible? I don't believe this statement is true. The problem is very hard to solve. Providing a generic component for doing this is far from trivial and arguable is very difficult. My advice again is to run you webapp using a profiler and use a tool to generate load. If you don't have a budget, you can use JMeter to monitor tomcat and generate load. This won't tell you exactly what causes the problem, but it could provide some hints. Real world user feedback was the main point of my postings. > And sorry for the tone again. > > -- > T. > > > The times that I've seen performance issues, it was our application doing bad things. Even simple things that one thinks "it should be ok" can cause performance degredation. good luck. peter
