tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hermes Flying <>
Subject Re: Fw: Can not understand how maxThreads of Connectors works
Date Thu, 24 Jan 2013 15:42:30 GMT
I don't see how this answers my issue.
1) You say 0 threads means 0 requests being processed. This does not happen. Requests are
being processed. No error noticed
2)You say: "you are setting your parameters in the wrong place". This is not the case here.I
already send an example server.xml. Will copy/paste it again bellow
3)"It does not seem to make a lot of sense to set up a whole machinery like a host, a JVM
and a Tomcat, just to process one single request at a time." I am not planning to do that,
but I must see how the system behaves in various configuration. Tomcat does not seem to behave
as expected in the trivial case.
4) "The default Tomcat settings are chosen by people who know what they are 
doing, to obtain a reasonable Tomcat behaviour over a reasonable range 
of conditions" What does this actually mean? That we are not supposed to configure Tomcat
according to our needs?

<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">

  <!--APR library loader. Documentation at /docs/apr.html -->
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html
  <Listener className="org.apache.catalina.core.JasperListener" />
  <!-- Prevent memory leaks due to use of particular java/javax APIs-->
 className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <!-- JMX Support for the Tomcat server.
 Documentation at /docs/non-existent.html -->
  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />

  <!-- Global JNDI resources
       Documentation at /docs/jndi-resources-howto.html
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    <Resource name="UserDatabase" auth="Container"
              description="User database that can be updated and
              pathname="conf/tomcat-users.xml" />

  <!-- A "Service" is a collection of one or more "Connectors" that share
       a single "Container" Note:  A "Service" is not itself a "Container", 
       so you may not define subcomponents such as "Valves" at this level.
       Documentation at /docs/config/service.html
  <Service name="Catalina">
    <!--The connectors can use a shared executor, you can define one or more named thread
 <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" 
        maxThreads="150" minSpareThreads="4"/>
    <!-- A "Connector" represents an endpoint by which requests are received
         and responses are returned. Documentation at :
         Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
         Java AJP  Connector: /docs/config/ajp.html
         APR (HTTP/AJP) Connector: /docs/apr.html
         Define a non-SSL HTTP/1.1 Connector on port 8080
    <Connector port="8080" maxThreads="0" acceptCount="1"
               redirectPort="8443" />

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

    <!-- An Engine represents the entry point (within Catalina) that processes
         every request.  The Engine implementation for Tomcat stand alone
         analyzes the HTTP headers included with the request, and passes them
         on to the appropriate Host (virtual host).
         Documentation at /docs/config/engine.html

    <!-- You should set jvmRoute to support load-balancing via AJP ie :
    <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">        

    <Engine name="Catalina" defaultHost="localhost">

      <!-- This Realm uses the UserDatabase configured in the global JNDI
           resources under the key "UserDatabase".  Any edits
           that are performed against this UserDatabase are immediately
           available for use by the Realm.  -->

      <!-- Define the default virtual host
           Note: XML Schema validation will not work with Xerces 2.2.
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true"
            xmlValidation="false" xmlNamespaceAware="false">


 From: André Warnier <>
To: Tomcat Users List <> 
Sent: Thursday, January 24, 2013 11:53 AM
Subject: Re: Fw: Can not understand how maxThreads of Connectors works
Hermes Flying wrote:
> Hi,
> So is there an explanation for this? All I am interested is make sure that after a limit,
clients attempted to connect are stopped based on my configuration on maxThreads and accept
> But I can not figure out how this works.

(This all being explained in vernacular language to which experts may object).

Threads in Tomcat serve to process requests.  Each Thread can process one request.
0 Threads = 0 requests being processed.
n Threads = n requests can be processed simultaneously (kind of).

Threads "belong to" either a Connector (by default), or an Executor (if you configure several
Connectors to use an Executor, then they use the common pool of Threads of the Executor, instead
of their own individual pool of Threads).

Having a common pool of Threads between several Connectors is normally more efficient and
allows for a smoother operation.  Otherwise you could have the case that requests arriving
through one Connector (e.g. HTTP) are being starved because this particular Connector has
no more Threads available, while on the other hand another Connector (e.g. AJP) still has
plenty of capacity.

The "acceptCount" is another matter entirely, working at a deeper level.
Before a Thread is assigned to process a request,
- the client requests a TCP connection to the server
- the server must "accept" this connection. If it doesn't within a certain time, the client
will get an error (connect timeout).
- when the server accepts the connection, it goes into a queue. The length of that queue corresponds
to the acceptCount of the corresponding Connector.
(If the accept queue is already full, the connection request will be rejected).
As long as the server does no further action, an accepted connection stays in the queue and
the client request does not proceed. If that lasts a long time, the client may timeout (usually
saying that the server is not responsive).
- whenever the server feels like it (for example, when it sees that it has at least one Thread
free to handle a request), it will pop the first connection from the accept queue, and pass
it to a Thread to be processed.
Now a Thread is assigned to process this request, so one less Thread is available in the pool
of Threads.
- if another client connection happens now, it goes into the accept queue.
- whenever the original Thread is done processing the request, the Thread goes back into the
pool of available Threads, and could be assigned to another client request currently sitting
in the accept queue.

That's roughly how it works.
If it does not do so in your case, then it must mean that you are setting your parameters
in the wrong place, and Tomcat is either not seeing them at all, or ignoring them because
they are not where they should be.

The default Tomcat settings are chosen by people who know what they are doing, to obtain a
reasonable Tomcat behaviour over a reasonable range of conditions.
If you change these settings, you can get a behaviour that is no longer reasonable or balanced.
For example, if you set the accepCount to 1 and maxThreads to 1, then you can have the following
- 1 request accepted and allocated a Thread, thus in process
- 1 additional request being queued in the accept queue, waiting for a Thread to become available
And any additional client request arriving at that time will be rejected at the TCP level. 
That will hardly result in an error that is understandable by the clients.

Intuitively, it does not seem to make a lot of sense to set up a whole machinery like a host,
a JVM and a Tomcat, just to process one single request at a time.

To unsubscribe, e-mail:
For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message