Welcome to TomcatExpert


You Can Help Improve Apache Tomcat Adoption in the Enterprise!

How? Share your insights, use cases, comments and questions on best practices for deploying, managing and operating Apache Tomcat in the Enterprise.


Blog : Understanding the jdbc-pool performance improvements

posted by fhanik on March 24, 2010 12:12 PM

In our previous article we gave a short introduction to a new module,  jdbc-pool, currently being development inside of Apache Tomcat's subversion development branch as a high concurrency alternative to connection pooling.

One of the main reasons this module was started was performance. In this article we will show you how to benchmark your tests and also share some performance numbers on the high-concurrency connection pool.

You can run these tests yourself against an in-memory database. Assuming you have Java 6, Ant and SVN installed simply follow these steps:

svn co
cd jdbc-pool
ant test

In our test runs we used a local MySQL database on a Solaris machine. While there is some overhead in creating a connection to MySQL, in our tests, this is a one-time affair, as we are testing pooled connections.

Read More



Developers, Operations | connection pool, DBCP, high concurrency

Blog : Apache Tomcat Self Support is “Free”...Or Perhaps Not!

posted by avanabs on March 19, 2010 06:34 AM

How to lose a half million dollars on one bug!

I want to share with you a recent experience from one of my clients. They have been using Apache Tomcat for several years, often combined with WebSphere (they are a “Big Blue” shop end to end) for supporting back office stateful applications. Early on, they decided to support Tomcat themselves, primarily because they did not find any viable vendors, but mostly because the development team (who had been using Tomcat on their desktops) convinced management that this would be “virtually free”. “No problem!

This has worked very well, particularly while the original Tomcat aficionado continued to provide "support" and...unknown to management...enhancements. There have been only occasional issues, easily handled by their in-house application programmers, with occasional help from the Tomcat community. No one even bothered to keep track of time spent maintaining Tomcat, because it was “free”. Over that time, however, their Tomcat version has diverged from the Apache project, because maintaining compatibility wasn't an objective, because the cost (mostly developer time) to submit their fixes to the Apache community wasn’t in anyone budget, and partly because re-integrating ongoing Apache changes was also un-funded drudgery. So, this organization is “using Tomcat” as far as management knows, but is actually using a diverging branch. All that said, the process continued to work fine and the visible costs were indeed low.

About a month ago, a new application was developed and put into test. This application was fairly simple, but it was projected to generate $ 100,000/week (TINY by their standards) initially, ramping up to over a half million/week by Q3. It was also the first visible peek at a new business strategy. The problem was that the application failed erratically during test. Subsequent debugging indicated this was due to a bug in Tomcat, not the application, so one of their application guru’s quickly rolled out a Tomcat bug fix (enhancement???) and delivered the result back to test.

At first, everything seemed fine. The new application worked great and passed thru QA with flying colors. “Free” self support won again…or did it? Application developers working on other projects fairly rapidly found that the new version was breaking some of their legacy applications, including several commercial apps. So, the application developer went back to the drawing board and quickly generated another fix.The new application failed, as did almost everything they tried to run. So, the process continued, with more than two dozen fixes generated and tried, and generated and tried, and…

Read More



Executives, Operations | branch, Self Support, Support

Blog : 3 Different Schools of Thought for Managing Production Apache Tomcat Infrastructures

posted by MSacks on March 17, 2010 06:24 AM

There are three schools of thought on how to achieve the same task of managing a large production Tomcat infrastructure: distributed command-line solutions,  custom tools using Java Management Extensions (JMX), and full-blown commercial software suites designed for managing Tomcat specifically.  All of the methods and utilities for managing Tomcat have their own respective tradeoffs of elegance, simplicity, manageability, and cost.

Tomcat Manager Application

The Tomcat Manager application is an excellent utility for managing Tomcat server. It has built-in support for deploying and un-deploying applications, reloading applications, gathering statistics about the JVM and Web application, as well as starting and stopping applications. IT even includes a Web-based JMX proxy where a user can modify and query MBeans through the manager application.

Where it falls short is that it primarily only supports functions for performing management operations at the servlet container level and above. It doesn’t allow a user to restart, start or stop the JVM that the Tomcat instance runs on from this Web interface and doesn’t have a built-in method for managing groups of Tomcat servers.

1) Command Line and Scripted Interfaces

The simplest method is using ssh-keys and shell/Python/Ruby/Groovy scripts, which requires little effort to implement, but lacks in elegance. There are a number of service wrappers that support automatic restarts on failure, schedule restarts and taking thread dumps on failure, but they don’t come with a good interface through being managed remotely by a Java standard such as JMX.

Many institutions implement homegrown or scripted solutions for managing large Tomcat infrastructures. When dealing with anything beyond 10 Tomcat servers, it becomes tedious to log into each host and start and stop each Tomcat instance.

Many solutions exist for running a distributed command against a large group of Tomcat clusters. Some organizations set up SSH keys on all hosts and use a scripted or CGI Web interface to send a single command to a large group of servers; however, when dealing with thousands of hosts, installing the keys can become a tedious task, and without a configuration management utility, such as Puppet or Cfengine this can consume a large amount of time to perform.


Read More



| cfengine, hyperic hq, java services wrapper

Blog : Explaining jdbc-pool, a High Concurrency Alternative to Connection Pooling Module

posted by fhanik on March 12, 2010 02:23 PM

Why another connection pool project

In this article we are going to explore one of the modules that is being developed in the Tomcat development trunk. The module named, jdbc-pool, is exactly that, an implementation of pooling of JDBC resources.

Connection pools have been around for a long time. I wrote one myself in 1997 when I first was introduced to Java, and used that for a long time in different projects I worked on. When JDBC came up, developers quickly realized that pooling JDBC connections would be beneficial for performance, and also a way to siphon connections and control the resource usage on the database server. This was especially important in horizontally scaled clusters where the database was always a risk of being overloaded. In those days we typically ran 1, 2 and sometimes 4 CPU machines for the application servers.

Connection pooling quickly became something that J2EE vendors developed in-house to integrate with their transaction services and became proprietary and integrated into the server itself. Outside of the J2EE containers a number of open source projects popped up. A few examples are Proxool, Apache Commons DBCP, C3P0 and Poolman. These are the most common ones we encounter in the field. Apache Tomcat has for very many years relied on DBCP to provide Tomcat users with a connection pooling implementation.

All of these open source projects have their pros and cons, but they all have something in common. They have become fairly stagnant and the code bases have not continued to evolve to meet new features in the Java language and are not optimized for multicore hardware that is increasingly becoming the common platform to deploy Java applications on. Some of the projects have also suffered from unneeded complexity in the source code, most likely one of the main reasons the project code is not moving forward, making it hard to maintain and easy to break.

Read More



Developers | Commons DBCP, connection pool, JDBC