Re: Limiting the number of connection threads per application

[Leon Rosenberg]

you could send the user to a waiting page, which should automatically
retry the action (via http redirect or js redirect) after some amount
of time.
On the other hand, if the waiting condition is almost permanent your
should think about other solutions...

regards
Leon

On 5/4/06, Ken Dombeck <[EMAIL PROTECTED]> wrote:

Thanks.

The problem with this solution is that the end user will then see the
SC_SERVICE_UNAVAILABLE error. The desired behavior is for the users
request to wait until a thread is freed up to process their request.

Is there way to do that?

-----Original Message-----
From: Greg Ward [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 04, 2006 4:20 PM
To: Tomcat Users List
Subject: Re: Limiting the number of connection threads per application

On 04 May 2006, Ken Dombeck said:
> We have 2 applications installed inside the same Tomcat 5.0 instance
> app1 and app2. URL app1.url.com is for app1 and app2.url.com is for
> app2. Both URLs have the same ip address but still hit port 80. The
> maxThreads for the connector is set to 100.
>
> The problem we are experiencing is that app2 will slow down and
> consume all 100 of the connector threads. What we would like to do is
> limit the number of threads that each application can use to 50 so
> that one application can not cause a denial of service attack to the
> other applications in the container. By limiting the number of
> connections to 50 we would expect the 51st connection to that
> application to wait until a thread freed up.

Wow, I asked this very same question just the other day.
Tim Funk <funkman at joedog dot org> kindly provided the following
suggestion:

> An "easier solution" is to throttle the webapp via a filter. For
example:
>
> Filter{
>   final int maxThreadCount=10;
>   int threadCount=0;
>   doFilter() {
>     synchronized(this) {
>       if (threadCount>maxThreadCount) {
>         response.sendError(SC_SERVICE_UNAVAILABLE);
>         return;
>       }
>       threadCount++;
>     }
>     try {
>       chain.doFilter(request, response);
>     } finally {
>       synchronized(this) {
>         threadCount--;
>       }
>     }
>   }
> }

I have implemented something like this for us and it works like a charm.
Haven't got it into production yet though.

Oh yeah, Tim's pseudo-code has an off-by-one error in it: I ended up
using the equivalent of

  doFilter() {
    synchronized(this) {
      if (threadCount >= maxThreadCount) {
        response.sendError(SC_SERVICE_UNAVAILABLE);
        ...


And if your problem is at the level of whole webapps, make sure you
apply the filter to whole webapps.  Here's a snippet from my web.xml
that configures this filter:

    <!--
    Filter to throttle the number of concurrent requests across the
    whole webapp.
    -->
    <filter>
      <filter-name>throttle</filter-name>

<filter-class>com.intelerad.web.lib.RequestThrottler</filter-class>
      <init-param>
        <param-name>max_concurrent_requests</param-name>
        <param-value>5</param-value>
      </init-param>
    </filter>

    <filter-mapping>
      <filter-name>throttle</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>

The <filter-mapping> is the important part to make sure it covers a
whole webapp.

        Greg

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]