Tomcat max connections on a per context basis

Question

I have multiple web applications running under a single Tomcat container. Since they all run under a single Tomcat connector (as defined in the server.xml file), attributes such as maxConnections and maxThreads govern the container as a whole. As a result it is possible for a single application to consume all available Tomcat threads, starving the other applications of threads and making them unresponsive. I would like to be able to define the maximum http threads on a per context basis so that this is no longer possible.

Here's what I've tried so far:

Create a custom filter in the application that keeps track of the current thread count and limits additional connections. (Got the filter here: How to set limit to the number of concurrent request in servlet?). I'm not sure I like this solution, as it isn't as full-featured (support for attributes such as acceptCount, maxConnections, maxThreads, and minSpareThreads) as Tomcat provides by default to the container; and adding in the features feels like I am attempting to build what already exists in Tomcat.
Create a separate Tomcat connector in the server.xml file for each context. This has a few issues. For one, each connector requires a separate port; this means I'll have to account for this in my apache config. Secondly, I plan to add more webapps regularly; this means a config change followed by a tomcat restart, which is disruptive to clients.

Has anyone else encountered something like this? I feel like there should be a "Tomcat supported" workflow to accomplish what I'm after.

I would say you nailed it. Thats one reason why using one app server to manage a bundle of application is pretty outdated. And there is no other solution then defining a own connector per application. — Paul Wasilewski
@PaulWasilewski Do you have any details on what a more modern approach might be? Single Tomcat instance per app? — Staros
@Staros, yes this is would be one approach. But that would be hard to manage. You should use frameworks like Spring Boot, Dropwizard or Play to get rid of your external app server instance and let the server be part of your code. Take a look at jaxenter.com/java-application-servers-dead-1-111928.html — Paul Wasilewski
@PaulWasilewski thanks for the feedback. I followed this tutorial to prove that it's not difficult to embed Tomcat into your application without the help of the frameworks you listed (as the migration would be quite painful): oracle.com/webfolder/technetwork/tutorials/obe/java/…. — Bryan Larson
@BryanLarson, I don't know much about your application and sure there are more ways then the frameworks I have mentioned. — Paul Wasilewski

Bryan Larson Bryan Larson · Accepted Answer · 2016-10-18T20:41:46

I'm going to post an answer that was provided to me from the Tomcat user group: http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Semaphore_Valve (The Semaphore Valve is not Tomcat 9 specific, but was actually introduced in Tomcat 6). I experimented with this concept, and I found the following practical applications:

(Untested) The Semaphore Valve should be able to be nested within the Host element in the server.xml file.
(Tested) A [context-name].xml file can be placed inside [tomcat-home]/conf/Catalina/localhost with the valve nested within the Context element.

This is not necessarily the solution that I am going with, as more testing will need to be performed. However, I thought I'd add this as it is a potential answer to the problem.

Update:
As a recap, the SemaphoreValve was an option that was recommended to me through the Tomcat user mailing list as a solution to the issue that I described above. It turns out it was easier to implement than I anticipated. Adding the following to context.xml in the Tomcat/conf directory did the trick:

<Valve className="org.apache.catalina.valves.SemaphoreValve" 
       concurrency="10" 
       fairness="true" />

Thanks to Mark Thomas from the Apache group for supplying the solution.

Tomcat max connections on a per context basis

1 Answers