gumdrop is a multipurpose Java server using asynchronous I/O. It provides a servlet container implementing the servlet 2.4 specification. Because the number of threads in the gumdrop servlet container is independent of the number of concurrent connections, it can scale much better than traditional Java web servers like Tomcat. It also avoids dependency on large, slow libraries and is therefore quite fast ☺. It is, however, 100% Java code. Projects are under way to provide HTTPS and JSP support for gumdrop. Future directions also include FTP and WebDAV connectors.

You can get a copy of gumdrop by following these instructions. gumdrop is distributed under the GPL.

If you have any questions, please direct them to Chris Burdess.


The server is configured with a number of connectors, which are bound to ports. It then sits in a select loop waiting for socket data. When an accept request is received, it uses the corresponding connector as a factory to create a new connection object to handle that IP connection. Subsequent read requests are demultiplexed to the corresponding connection handlers. Servers based on an asynchronous, or reactor, model can thus be developed quite quickly in response to incoming data.

The servlet container is a rather special case. The servlet connector spawns one or more request handler threads, which wait on a queue of request/response pairs. As data arrives sufficient to construct a request, a request/response pair is initialised (from a pool) and placed in the queue. The request body arrives asynchronously via a pipe. The request handler thread can therefore block waiting for request data while the server supplies it.

Because the number of request-processing threads is completely independent of the number of client TCP connections to the server, gumdrop scales very gracefully in comparison to traditional web servers.

Servlet contexts marked as distributable cause gumdrop to start another thread, used for cluster synchronisation. The mechanism used is a simple UDP broadcast of the changed session data.

Unless otherwise configured, containers also use a separate thread to detect changes in the web application configuration, such as recompilation of Java classes and changes to the deployment descriptor. Such changes cause the context to be reloaded. This process is referred to as hot deploy.


The configuration of gumdrop is primarily contained in the gumdroprc file. The remainder of the configuration is supplied by standard Java system properties, e.g. the logging subsystem which uses the java.util.logging package.

Format of the gumdroprc file

The gumdroprc file is an XML file, although it is not intended to be validated, as it may contain attribute names that are specific to properties of the resources to be configured, and which can therefore not be known in advance. However, here is the general format of the file:

Where to go from here

Hopefully you will try out some of your own web applications within gumdrop. If the speed, simplicity, and ease of configuration appeals to you, please consider getting involved and developing a new feature. If it doesn't work the way you wanted it to, please let us know!

There are a number of new features planned for gumdrop. We are working on TLS support, which will provide HTTPS capabilities for the servlet container. JSP support is not actively planned, but if you want to work on that, so much the better. In the longer term, the plan is to add a number of asynchronous servers (e.g. FTP, WebDAV) and also to develop intelligent algorithms for spawning and reaping request-processing threads based on demand. If you have an idea, we'd love to hear that too.