Hermes Flying wrote:
Hi,
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
It is not only me saying it. The on-line documentation at
https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
says this :
quote
maxThreads
The maximum number of request processing threads to be created by this Connector, which
therefore determines the maximum number of simultaneous requests that can be handled. If
not specified, this attribute is set to 200. If an executor is associated with this
connector, this attribute is ignored as the connector will execute tasks using the
executor rather than an internal thread pool.
unquote
Now, considering this, there are a number of possibilities :
- the documentation is totally wrong
- there is a bug in Tomcat
- your Tomcat server is not using this server.xml
- or, it being rather unlikely that processing 0 requests is what a normal user would
want, the Tomcat developers have coded this so that an obviously nonsensical value of 0
would result in the default (of 200) being applied.
Pick any one of the above.
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
Yes, but we cannot check from here if this is really the server.xml that your Tomcat is
reading. Are you absolutely sure it is ? How ?
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.
The "trivial case" is 0 Threads ? What happens when you set it to 1 ?
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?
Of course you can. But if you are using nonsensical values, do you expect a sensible
behaviour ?
Come on, man. This is open-source software, that you get to use for free.
This is not to say that it is not good software, nor that the developers do not try to
make it as efficient and reliable as possible, nor that the people writing the
documentation (also for free) do not make every effort to write it well and accurately.
On the other hand, it is kind of expected that people using Tomcat and configuring it,
would use a bit of judgment and give the developers a bit of slack.
I am not a developer of Tomcat, but what I tried to provide in my explanation is a
guideline as to how these parameters are supposed to work. That was to help you maybe find
the reason for what appears to you as "not working", but which apparently other people
cannot reproduce.
I just tried with Tomcat 6.0.24 under Windows, and when I set
maxThreads="0" in the HTTP Connector, Tomcat starts up without error in the log. But if I
try to access it with a browser, the browser loops saying "connecting.." and never goes
past that point. If I set maxThreads="1", then Tomcat is answering with the homepage.
Same thing with Tomcat 7.0.21.
So I would say : check that the server.xml below is really the one that Tomcat
is using.
(Additionally, I would say that it seems that when Tomcat is configured to not have any
Threads to process requests, well it just does not process any. Which seems to me like
sensible behaviour under adverse circumstances.)
<?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-->
<Listener
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
-->
<GlobalNamingResources>
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and
saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<!-- 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 pools-->
<!--
<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"
protocol="HTTP/1.1"
connectionTimeout="20000"
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. -->
<Realm
className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
<!-- 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">
</Host>
</Engine>
</Service>
</Server>
________________________________
From: André Warnier <a...@ice-sa.com>
To: Tomcat Users List <users@tomcat.apache.org>
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 count.
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
