Filip Hanik's blog

Blog : How Apache Tomcat Implemented WebSocket

posted by fhanik on May 1, 2012 07:13 AM

With the Apache Tomcat 7.0.27 release, the Apache Tomcat team introduced a WebSocket implementation. In a previous post, we took a look at what the WebSocket implementation means, including what benefits and limitations they present. Today, we will discuss specifically how WebSocket is implemented in Apache Tomcat 7.

Since WebSocket is a protocol sent over TCP after an initial HTTP handshake, you could effectively implement WebSocket using Tomcat’s Comet implementation. There is a back port to Tomcat 6 suggested that does exactly that with very minor changes.

The Apache Tomcat team however decided to go with a more substantial implementation with changes to the core of Tomcat’s network and protocol implementation. The reason for this was memory and scalability based. If Tomcat can recycle the HttpServletRequest/Response objects after the initial handshake, each WebSocket connection will take up less memory in the Java heap. It also opens up the Tomcat container for other future protocols that utilize the HTTP Upgrade feature.

The WebSocket implementation from an API standpoint is fairly straightforward. You really can only do two things:

  1. Send messages
  2. Receive messages

Read More



Developers, Operations | WebSocket, Apache Tomcat 7

Blog : WebSockets in Tomcat 7

posted by fhanik on April 23, 2012 10:22 PM

With the 7.0.27 release the Apache Tomcat team introduced a WebSocket implementation. WebSocket has received a lot of hype, and has been much anticipated by Tomcat users. Let’s take a quick look at what web sockets are, what benefits and limitations they have and how they are implemented in Apache Tomcat 7.

What is a WebSocket?

WebSocket is considered the next step in evolution of web communication. Over time, communication has evolved in steps to reduce the time and data throughput for the application to update a user’s browser. The evolution has looked a little like this:

  • Entire page reloads
  • Component reloads using AJAX Processing
  • Comet communication
    • Long poll– similar to AJAX, but not holding a thread on the server
    • Bi directional- two way communication over the same TCP

Each of these steps had their benefits and challenges. Apache Tomcat 6 implements bi-directional communication over HTTP using its Comet Processor. This implementation allowed for asynchronous event driven request processing as well as bi-directional communication. This implementation had a few limitations.

Read More



Developers | WebSocket, Apache Tomcat 7

Blog : Understanding Apache Tomcat: Getting Started

posted by fhanik on October 19, 2011 07:39 AM

Apache Tomcat, and other containers, have been around for so long today that it has become increasingly harder to get started with them today.

In this article, we will take you back from the beginning with how to get started with Apache Tomcat. We will go into the lowest level, so you don't have to rely on an IDE or other system to get started. This article is written for those that have never used Apache Tomcat and wish to get started in an easy, yet explanatory, way that helps you to understand what is happening under the hood. This will fast track you to become very proficient with this light weight application server.

Step 1. Download and Install Apache Tomcat

While there are a lot of different packages available to install Tomcat, for example some Linux distributions you can download it using that distributions package and dependency management. This is good, for the sake of simplicity, but once again, you lose the concept of what Tomcat is and what true dependencies it has as well on how to use it.

I strongly recommend only moving to a third party packaging of Apache Tomcat after you understand the container itself. This will help avoid complications when you try to create a plan for how you distribute, upgrade and maintain your software.

Rule 1. When learning, only download the software from

Now, since you are learning Apache Tomcat from scratch, I suggest you start with Apache Tomcat 7.  As explained in an earlier post,  the majority of features that are implemented, are driven by the (Servlet) and (JSP) specifications.  Each time the Servlet specification is upgraded, new features added, the Apache Tomcat will plan for a new major release of Apache Tomcat. The latest version, Apache Tomcat 7,  is based on the version of the Servlet specification, in this case, Servlet 3.0.

Read More



Developers, Operations | Apache Tomcat 6, Apache Tomcat 7

Blog : Building extensions to jdbc-pool

posted by fhanik on April 19, 2010 06:08 AM

In our previous blog posts, 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. We also covered jdbc-pool performance and how to cconfigure jdbc-pool for optimal performance.

In this article we'll dig a bit deeper under the covers and take a look at how to build extensions to the jdbc-pool. To do this, we will build a prepared statement cache for the jdbc-pool using the interceptors as a base.

A note of caution

Personally, I don't believe that connection pools should perform any level of statement caching. Here are a few reasons why:

  • Statements represent resources on the database back end. Hence this cache leads to increased resources usage.
  • Statement caches belong on the database, in worst case in the JDBC driver. But not in a connection pool.
  • The overhead of preparing a statement can be cached and optimized on the database, rather than at a much higher level, since the overhead mainly is related to the parsing of the query.
  • Statements have to be cached on a per connection basis, not making it an optimal cache for a connection pool
  • There is an API to allow the underlying driver/database to handle it using the setPoolable call.
    If you take a look at a number of databases, these databases already have facilities for caching and optimizing statements, take DB2 dynamic statements as a simple example.

Setting up the interceptor

Most of the extensions in jdbc-pool can be accomplished using the JDBC interceptor base class. The interceptors all extend the invocation handler interface.

This means, that any method invocations on the Connection interface will pass through the

Object invoke(Object proxy, Method method, Object[] args) throws Throwable;

method. So if the user is calling javax.sql.PooledConnection.getConnection method we could implement that as:

1:  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
2:    if (method.getDeclaringClass().equals(PooledConnection.class) &&
3:        compare(GETCONNECTION_VAL,method) { 
4:        return connection.getConnection();
5:    } else {
6:        return super.invoke(proxy,method,args);
7:    }
8:  }
  • Line 2 - We check that the interface that is being called is the javax.sql.PooledConnection.getConnection class
  • Line 3 - We check that the method being called is getConnection
  • Line 4 - We return the underlying connection
  • Line 6 - If the above conditions have not been met, pass on the request to the next interceptor.

Read More



Developers, Operations | connection pool, Tomcat 7, Tomcat Admin

Blog : Configuring jdbc-pool for high-concurrency

posted by fhanik on April 1, 2010 03:19 PM

In this article we will focus on configuration of the high-concurrency connection pool. For ease of migration for Tomcat users, the configuration has been written to mimic that of Commons DBCP.

The documentation of jdbc-pool covers all the attributes. Please note that these attributes are also available as direct setters on the org.apache.tomcat.jdbc.pool.DataSource bean if you're using a dependency injection framework. So in this article we will focus on use cases, and different configurations for Tomcat.

Simple Connection Pool for MySQL

<Resource type="javax.sql.DataSource"

The first thing we notice is the factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" attribute.
When Tomcat reads the type="javax.sql.DataSource" it will automatically configure its repackaged DBCP, unless you specify a different factory. The factory object is what creates and configures the connection pool itself.

There are two ways to configure Resource elements in Apache Tomcat.

Read More



Developers, Operations | connection pool, DBCP, high-concurrency

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 : 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

Syndicate content