tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Limiting threads per context
Date Fri, 04 Jan 2013 23:14:06 GMT
Hash: SHA256


On 1/3/13 3:49 PM, Felix Schumacher wrote:
> Am 03.01.2013 15:31, schrieb
>> Hello All,
>> Yesterday we had a Tomcat6 server reach maxThreads and stay that
>> way until we restarted it.  After researching a thread dump and
>> some log files, we found one of the applications is creating
>> NullPointerExceptions and subsequently leaving a TP-ProcessorX in
>> WAITING state indefinitely for a DB closePreparedStatement
>> return.  As more requests come in for this application threads
>> are being established and put into BLOCKED state, waiting on
>> TP-ProcessorX.  Eventually, the server hits maxThreads and stops 
>> serving requests almost entirely.
>> Obviously the application causing this needs to (and is being)
>> fixed. But I'm curious if there is a higher level of protection
>> that could be implemented to help protect the other applications
>> (contexts) on this server?  For example, is there a way to
>> specify that a context can only use X number of request threads?
>> Or perhaps X number of threads from an executor?  Et cetera.
> On tomcat 6 - at least the most recent one - there is a Valve which
> can limit the concurrent access to a context. Sadly it seems not to
> be mentioned in the docs. So you would have to look at the code to
> see the possible params (concurrency [=10], fairness [=false],
> blocking [=true], interruptible [=false]) and the name 
> (org.apache.catalina.valves.SemaphoreValve) to be able to add the 
> (hopefully) right entry to your context:

The last modification to that class was 2010-04-29, so everyone should
have it by now. Then again, lots of people are still running 5.5.8 or
whatever, so what do I know...

> <Valve class="org.apache.catalina.valves.SemaphoreValve" 
> concurrency="25" blocking="false" />
> I haven't tested it, but it should limit the concurrent threads
> used by that context to 25 at most and give an error to any request
> while those threads stay busy.

Note that blocking=false will likely result in lots of requests being
essentially rejected: the client will get a 200 OK response with no
content at all. On the other hand, if you allow blocking, then the
result will be the same as if the valve hadn't been installed: all
requests will wait until all of them are stuck in the
"closePreparedStatement" trap.

The point is that installing the SemaphoreValve will merely change the
exact circumstances under which this application comes grinding to a
halt. If you are trying to protect *other* webapps from this problem,
then use of the SemaphoreValve might be of some use. Otherwise, the
effect will be of simply lowering the maxActive setting on your
<Executor> (with the notable exception that clients will immediately
get a useless response instead of waiting forever for no response).

(If you subclass the Valve and override the permitDenied method, you
can return any response you wish, which might be a good idea.)

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with undefined -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message