RE: Increasing maxThreads results in more "Connection refused" errors?
Chris > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Friday, February 03, 2017 11:08 AM > To: Tomcat Users List > Subject: Re: Increasing maxThreads results in more "Connection refused" > errors? > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John, > > On 2/3/17 11:17 AM, john.e.gr...@wellsfargo.com.INVALID wrote: > > I'm doing some scalability testing of an app in Tomcat 7.0.73. > > > > Some relevant connector config details: maxThreads=80 > > maxKeepAliveRequests=100 keepAliveTimeout=1 maxConnections > > unspecified (defaults to maxThreads according to the docs) acceptCount > > unspecified (100 according to the docs) clientAuth=true > > Which connector? > > > FWIW, I'm testing two Tomcat instances on the same server. They are > > behind a load balancer. > > Which load-balancer using which protocol? > > > It appears that when the load generator tries to exceed maxThreads, > > the new connection rate goes up quickly and CPU usage shoots up with > > it. > > When you say the "new connection rate" goes up, what exactly do you mean? > When using a load-generator, I would certainly expect the "new connection > rate" to go up. > > > I assume this is because Tomcat is proactively closing idle keep alive > > connections to service new connections. > > No. Tomcat behaves the same under load as when not under load. If you are > using the BIO connector (it sounds like you are), then each connection will > have > to wait for the KeepAlive timeout to expire before servicing another request > from another client. > > This is complicated by the reverse-proxy and so those details are important to > provide. > > > In an effort to keep the CPU in check, I tried increasing maxThreads > > from 80 to 120. > > If the CPU is very busy, allowing more threads to run is counter-productive, > isn't > it? > > > This seemed to work well in a lot of ways. New connection rate didn't > > increase as much, CPU didn't increase as much, there was more > > connection reuse (more requests per connection,) and response times > > didn't deteriorate as much. > > > > Great, right? > > > > Then I noticed a large increase in "Connection refused" errors on the > > load generator. In other words, a higher maxThreads also results in a > > high error rate. The total hits per second from the client's > > perspective is about 60 in both cases. With maxThreads=80, there are > > about 3 connection refused errors per second at that volume. With > > maxThreads=120, there are about 10 connection refused errors per > > second. > > Are you hitting the load-balancer or Tomcat directly during your load-test? > > If you are hitting the load-balancer, then the details of that configuration > are > more important for the client: if the lb will only accept 10 connections, it > doesn't > matter what Tomcat is willing to accep t. > > > I have no idea why this is. Can someone explain this or what I can do > > about it? > > Post more data. We'll get to the bottom of it. > > - -chris Thanks for asking those good questions. When I checked with the load balancer people, they told me there was a 70 connection limit to each Tomcat server enforced by the load balancer. It took a while to get that limit removed, but now that it's gone, the connection errors completely went away. I think the limit is a good idea and we will probably re-establish a higher one after additional testing. Thanks John
Re: Increasing maxThreads results in more "Connection refused" errors?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 2/3/17 11:17 AM, john.e.gr...@wellsfargo.com.INVALID wrote: > I'm doing some scalability testing of an app in Tomcat 7.0.73. > > Some relevant connector config details: maxThreads=80 > maxKeepAliveRequests=100 keepAliveTimeout=1 maxConnections > unspecified (defaults to maxThreads according to the docs) > acceptCount unspecified (100 according to the docs) > clientAuth=true Which connector? > FWIW, I'm testing two Tomcat instances on the same server. They > are behind a load balancer. Which load-balancer using which protocol? > It appears that when the load generator tries to exceed > maxThreads, the new connection rate goes up quickly and CPU usage > shoots up with it. When you say the "new connection rate" goes up, what exactly do you mean? When using a load-generator, I would certainly expect the "new connection rate" to go up. > I assume this is because Tomcat is proactively closing idle keep > alive connections to service new connections. No. Tomcat behaves the same under load as when not under load. If you are using the BIO connector (it sounds like you are), then each connection will have to wait for the KeepAlive timeout to expire before servicing another request from another client. This is complicated by the reverse-proxy and so those details are important to provide. > In an effort to keep the CPU in check, I tried increasing > maxThreads from 80 to 120. If the CPU is very busy, allowing more threads to run is counter-productive, isn't it? > This seemed to work well in a lot of ways. New connection rate > didn't increase as much, CPU didn't increase as much, there was > more connection reuse (more requests per connection,) and response > times didn't deteriorate as much. > > Great, right? > > Then I noticed a large increase in "Connection refused" errors on > the load generator. In other words, a higher maxThreads also > results in a high error rate. The total hits per second from the > client's perspective is about 60 in both cases. With maxThreads=80, > there are about 3 connection refused errors per second at that > volume. With maxThreads=120, there are about 10 connection refused > errors per second. Are you hitting the load-balancer or Tomcat directly during your load-test? If you are hitting the load-balancer, then the details of that configuration are more important for the client: if the lb will only accept 10 connections, it doesn't matter what Tomcat is willing to accep t. > I have no idea why this is. Can someone explain this or what I can > do about it? Post more data. We'll get to the bottom of it. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYlLjdAAoJEBzwKT+lPKRYRyYQAKs8F2HQ60cmlInZuubIQaq5 MuJxMZV/rCSgFMwoBzR+KDMS2PlTUvpoUMlp3/tTz8oON4x6j3jGzQdA9EGcjje4 W7D/G6TmoMptjeI8Zz0UbYnIRM5JXEvxOzuuGURbER7iCaa9VVsoWnhcv+Ja02Ut Xl9dzEwFpfXasr8ioHL5Yn4W7F0QUDz9vboBQ/9TwYAib9UAKEP8uzWWjh6ylLaw Z9ShyJtCU5rQ47ZVYhCcd+ZgCnP0sbcjD9kloD29dDFHgALTWPuAQA50ZDPiAUBR I0WuDMGITpsl0ni4jbwMjrnv3voaVD0HtSCZon6fynux2BciaHVGx8s0lGtRMz6v isG5L6+io8JR3asNdb8Ug3G+5zX8FMZx5VwlsQNVqo10xsEXYosACtqTmASyLPx6 EwgLDnCeMwKK3A6hmKqw0aEl1R9TqlpLKK5h9g7+RPpm6imUdsZvHAjSL3OWJa8e Laqujf8MxCN/DsZhKOocwv5F98zcsn/mD9VZ/2IG+78JqfB3qU4wa5brD11n71xe uYMgGIH0zIGN9ZGRtWdAbPbY2JIu2qIkFzz06hgYr/W5QLrZzy2dGYkyGBPMHrDV TPR1+EbNNOtGVq5IF6t8ZChOE6toNnIdWdy5bVNiXEhIpVXquWsfoysNVlBmyA4V VICVGii1G2WK9kfP7Q82 =UyRB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Increasing maxThreads results in more "Connection refused" errors?
All, I'm doing some scalability testing of an app in Tomcat 7.0.73. Some relevant connector config details: maxThreads=80 maxKeepAliveRequests=100 keepAliveTimeout=1 maxConnections unspecified (defaults to maxThreads according to the docs) acceptCount unspecified (100 according to the docs) clientAuth=true FWIW, I'm testing two Tomcat instances on the same server. They are behind a load balancer. It appears that when the load generator tries to exceed maxThreads, the new connection rate goes up quickly and CPU usage shoots up with it. I assume this is because Tomcat is proactively closing idle keep alive connections to service new connections. In an effort to keep the CPU in check, I tried increasing maxThreads from 80 to 120. This seemed to work well in a lot of ways. New connection rate didn't increase as much, CPU didn't increase as much, there was more connection reuse (more requests per connection,) and response times didn't deteriorate as much. Great, right? Then I noticed a large increase in "Connection refused" errors on the load generator. In other words, a higher maxThreads also results in a high error rate. The total hits per second from the client's perspective is about 60 in both cases. With maxThreads=80, there are about 3 connection refused errors per second at that volume. With maxThreads=120, there are about 10 connection refused errors per second. I have no idea why this is. Can someone explain this or what I can do about it? Thanks John
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
akshay,
On 1/26/14, 2:04 PM, akshay hiremath wrote:
On Friday, January 24, 2014 7:04 PM, Konstantin Kolinko
knst.koli...@gmail.com wrote:
2014/1/24 akshay hiremath akshay...@yahoo.com:
Through some trials found that its not enough to increase the
Executors thread count(maxThreads for Executor element) but also
need to increase the Connectors thread count(maxThreads for
Connector element). This behavior is not actually clearly
captured in tomcat documentation says
1. The rules: http://tomcat.apache.org/lists.html#tomcat-users
- 6. do not top-post, 7. do not send attachments
2. Are you sure that you are actually using an Executor?
In your original port there is no guarantee that the executor
attribute of your Connector matches the name of an Executor that
you declared. If the Executor does not exist, the attribute will
be ignored.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
1. The rules: http://tomcat.apache.org/lists.html#tomcat-users
- 6. do not top-post, 7. do not send attachments
Sorry about Top posting. i didn't know about top post issue. Now
I'm taking care of this.
In your original port there is no guarantee that the executor
attribute of your Connector matches the name of an Executor that
you declared. If the Executor does not exist, the attribute will
be ignored.
I'm using the Executor in the connector. In case if you have missed
my original post portions because of my wrong top posting.
server.xml content:
Executor name=tomcatThreadPool
namePrefix=${server.service-Catalina.executor-tomcatThreadPool.namePrefix}
maxThreads=${server.service-Catalina.executor-tomcatThreadPool.maxThreads}
minSpareThreads=${server.service-Catalina.executor-tomcatThreadPool.minSpareThreads}/
Executor's
name: tomcatThreadPool
Connector
executor=${server.service-Catalina.connector.http1.1.executor}
Executor reference:
${server.service-Catalina.connector.http1.1.executor}. Depending
upon the value of all that mess, you might not have the right executor
name.
How about showing us the segment of the server.xml that actually gets
used by Tomcat, instead of the ant-processed template file?
server.service-Catalina.connector.http1.1.executor=tomcatThreadPool
Are
you sure?
Try connecting with JMX and taking a look at the connector's executor
name.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS5oJvAAoJEBzwKT+lPKRYjPoP/1zfNtlQ0hgFDcl1mZ2eq+Jj
tqTKF/MsRBAOy+FA/eLp8KOaJpS/JpcjVmf7tXdIykeTCREcIgDUYWVgieOL+Imv
/FhQ2T+upqX0fAzleB3m/WKRMZnH6n9nmL/UpUr/6++L+d+IsCz4KqXSXazgOGIl
vJF9dVW+YcKh8bd43BYSjR/Sj54ucysNjr/OzJipjJFmVuIBa1djR+uCO+732r8A
PQCplEVzGCLDOhZepMc3mBXgBk5fAmTMm4QtCqAP3b2/BSwmi28vvR0Vom2rfnEF
OZXUuyZm++tMPSSRzsLUaCADC9+Dt+qyFvQ2IL7jGmxBrjSBY4jz1QZ8APpG1Kh7
CQXoPyXbJ/iKx/qFvZLscmcnGQZfK4h++lSZNy3Zx8qhD7BgbwKxQRC+c1BzXhgC
SLIeijO+wvcDVipUCYzki5zWDtVgdyGfEDOZ8MhOqrD6VA4hLONVcX4HkQXjqsjB
eB4KWpNJ3+q/rO6nCm8FqReXuawr6y6G9S10ZRrcF+eZj9cbn18G8JcHlE3rhwxh
3UoJDIUfPwyV+0jDc9aAacnzVdn1bQPbxvMxD3bAWFGOLDiQe+fZtEQKnAQnVmUz
1yY/3SWRLfqDZ47BKdMTZ/3rwfh8MZ6US+fBatZTU3AkvQk2k4WYvA4/BxwaoLXo
2V2+2DzR85y3gl0Jqu0W
=Eo47
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
On Friday, January 24, 2014 7:04 PM, Konstantin Kolinko
knst.koli...@gmail.com wrote:
2014/1/24 akshay hiremath akshay...@yahoo.com:
Through some trials found that its not enough to increase the Executors
thread count(maxThreads for Executor element) but also need to increase the
Connectors thread count(maxThreads for Connector element). This behavior is
not actually clearly captured in tomcat documentation says
1. The rules:
http://tomcat.apache.org/lists.html#tomcat-users
- 6. do not top-post, 7. do not send attachments
2. Are you sure that you are actually using an Executor?
In your original port there is no guarantee that the executor
attribute of your Connector
matches the name of an Executor that you declared. If the Executor
does not exist,
the attribute will be ignored.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
1. The rules:
http://tomcat.apache.org/lists.html#tomcat-users
- 6. do not top-post, 7. do not send attachments
Sorry about Top posting. i didn't know about top post issue. Now I'm taking
care of this.
In your original port there is no guarantee that the executor
attribute of your Connector
matches the name of an Executor that you declared. If the Executor
does not exist,
the attribute will be ignored.
I'm using the Executor in the connector. In case if you have missed my original
post portions because of my wrong top posting.
server.xml content:
Executor name=tomcatThreadPool
namePrefix=${server.service-Catalina.executor-tomcatThreadPool.namePrefix}
maxThreads=${server.service-Catalina.executor-tomcatThreadPool.maxThreads}
minSpareThreads=${server.service-Catalina.executor-tomcatThreadPool.minSpareThreads}/
Connector executor=${server.service-Catalina.connector.http1.1.executor}
port=${http.port}
protocol=${server.service-Catalina.connector.http1.1.protocol}
connectionTimeout=${server.service-Catalina.connector.http1.1.connectionTimeout}
redirectPort=${https.port}
acceptCount=${server.service-Catalina.connector.http1.1.acceptCount}
maxKeepAliveRequests=${server.service-Catalina.connector.http1.1.maxKeepAliveRequests}/
catalina.properties:
server.service-Catalina.connector.http1.1.executor=tomcatThreadPool
--Akshay
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
Through some trials found that its not enough to increase the Executors thread count(maxThreads for Executor element) but also need to increase the Connectors thread count(maxThreads for Connector element). This behavior is not actually clearly captured in tomcat documentation says A reference to the name in an Executor element. If this attribute is set, and the named executor exists, the connector will use the executor, and all the other thread attributes will be ignored. Note that if a shared executor is not specified for a connector then the connector will use a private, internal executor to provide the thread pool. all the other thread attributes will be ignored makes impression that its enough to increase the Executor thread count. As executor is a shared thread pool and connector is using that but what I seen is Referencing the Executor in Connector element and setting maxThreads for Executor is not enough. If we do that tomcat creates no. of threads as per maxThread configuration of Executor but not all threads are actually used for request processing. Even if we put more load the activeCount will never go above 200 that is default maxThreads value of Connector. To get threads more than 200 we have to additionally set the maxThread attribute for Connectors element as well. (irrespective of Executor reference) When I explicitly set maxThreads for Connectors activeCount actually went UP to the maxThreads limit. Now I'm able to reach activeCounts beyond 250 see attachment. On Thursday, January 23, 2014 8:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 akshay, On 1/23/14, 9:07 AM, akshay hiremath wrote: We have this HP load runner running a load of requests on this system. We don't see request rejected by Tomcat but if I monitor the activeCount attribute of Mbean Catalina:type=Executor,name=tomcatThreadPool over the period of test why the activeCount is not going above 200. if I continuously track activeCount and currentThreadsBusy of MBean Catalina:type=ThreadPool,name=http-bio-8080 I see the graph reahes 200 and flat lines there. Please find monitored graph attached during one of the tests. See time frm start of graph to the 13:30 when test ended. ignore the in between part and rest graph that is of another ongoing test. Attachments are stripped from the list. Find another way to express your thoughts. Is it possible that you are simply not generating enough load? If Tomcat is responding to all of your requests (e.g. none of them are failing to connect, failing to respond, or responding very slowly -- as if queued) than it sounds like your Tomcat instance is handling all the load you are throwing at it. - -chris On Thursday, January 23, 2014 7:06 PM, Mark Thomas ma...@apache.org wrote: On 23/01/2014 13:30, akshay hiremath wrote: Why tomcat is not able to have more than 200 active Threads (parallel threads) processng my requests? It can. The issue is that the combination of the requests you are making (which you fail to describe), your load testing framework (which you fail to describe) and the scheduling in the CPUs of your hardware (which you also fail to describe) mean that the chances of there actually being 300 concurrent requests for Tomcat to process is pretty much zero. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org mailto:users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org mailto:users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS4TH3AAoJEBzwKT+lPKRY1vQP/01g9bL731iYBYV9MQtDhLMJ LeBXfV2996qnpX2VftnltPGXq2V9/l93tjRMiDxrcaGIrdzebkzv+PegRdhIxto1 JeIJh9xBFKd+J/aWTmzDYLzE9/eGoGRW+R+G3MuqqBs3KSXaNbEDHtdB/5zzQ0Bj Ht7iWTvPyEkp3JeKBo/FM/nZG2cnBNwC+kNWkdzlOqPIWUVOPmbqQky2qkM86s+d 65trfkDDSkez1ws2bZJ42TbW3IR9Qv1H/YlMzMmr2BJpGUnTAIKwu0l+bD+kH8pT QQo7anuTpuygwsE30zO3FcgkwzTuPcccHTh0G1XvzCYFJJ+tnAa4h+0Z6GAu7q6E 5ltIyHZjp4KJoLulNFQfqlItjabi6XIUwwQk/Ob4pRpgfsORIwapusY1vFThwhJv m3M0fVgWmxCHc41ed+mMhUPewXqqv0iaXKj4oxuW9GSPfdlQ7wCECwcIR11K39aU Ff9dbEEFuT7yvKgQy589dsSycgydCONTS+4b/25stwR1VgxA2MlvhcF8LBNN3o8L kPefjrOQVGLAuwrSgBiAVsD9dNDis5UhQ0sdGUKoLSuI3HSy1KMANVUWjYmig4bP fUmhGlKiM9CknxUpDK/rdAGWUOQU06rXeWVitQ/2p42UQibtAhXuM+1ymw/v4zou SBh0nxrR6K0AVV8KhomP =TIpT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
2014/1/24 akshay hiremath akshay...@yahoo.com: Through some trials found that its not enough to increase the Executors thread count(maxThreads for Executor element) but also need to increase the Connectors thread count(maxThreads for Connector element). This behavior is not actually clearly captured in tomcat documentation says 1. The rules: http://tomcat.apache.org/lists.html#tomcat-users - 6. do not top-post, 7. do not send attachments 2. Are you sure that you are actually using an Executor? In your original port there is no guarantee that the executor attribute of your Connector matches the name of an Executor that you declared. If the Executor does not exist, the attribute will be ignored. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
I've a tomcat 7 instance with following configuration in
catalina.properties for threads
server.service-Catalina.executor-tomcatThreadPool.maxThreads=300
server.service-Catalina.executor-tomcatThreadPool.minSpareThreads=300
server.service-Catalina.connector.http1.1.executor=tomcatThreadPool
server.service-Catalina.connector.http1.1.protocol=HTTP/1.1
server.service-Catalina.connector.http1.1.connectionTimeout=2
server.service-Catalina.connector.http1.1.acceptCount=300
server.service-Catalina.connector.http1.1.maxKeepAliveRequests=15
server.xml configuration
Service name=Catalina
Executor name=tomcatThreadPool
namePrefix=${server.service-Catalina.executor-tomcatThreadPool.namePrefix}
maxThreads=${server.service-Catalina.executor-tomcatThreadPool.maxThreads}
minSpareThreads=${server.service-Catalina.executor-tomcatThreadPool.minSpareThreads}/
Connector executor=${server.service-Catalina.connector.http1.1.executor}
port=${http.port}
protocol=${server.service-Catalina.connector.http1.1.protocol}
connectionTimeout=${server.service-Catalina.connector.http1.1.connectionTimeout}
redirectPort=${https.port}
acceptCount=${server.service-Catalina.connector.http1.1.acceptCount}
maxKeepAliveRequests=${server.service-Catalina.connector.http1.1.maxKeepAliveRequests}/
I want 300 threads to serve the requests.
With above configuration tomcat starts 300 threads and I can see
through JConsole 300 worker threads are running. but when I hit with 300
concurrent requests load the activeCount goes just till 200.
Why tomcat is not able to have more than 200 active Threads (parallel
threads) processng my requests?
Thanks,
Akshay
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
On 23/01/2014 13:30, akshay hiremath wrote: Why tomcat is not able to have more than 200 active Threads (parallel threads) processng my requests? It can. The issue is that the combination of the requests you are making (which you fail to describe), your load testing framework (which you fail to describe) and the scheduling in the CPUs of your hardware (which you also fail to describe) mean that the chances of there actually being 300 concurrent requests for Tomcat to process is pretty much zero. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
We have this HP load runner running a load of requests on this system. We don't see request rejected by Tomcat but if I monitor the activeCount attribute of Mbean Catalina:type=Executor,name=tomcatThreadPool over the period of test why the activeCount is not going above 200. if I continuously track activeCount and currentThreadsBusy of MBean Catalina:type=ThreadPool,name=http-bio-8080 I see the graph reahes 200 and flat lines there. Please find monitored graph attached during one of the tests. See time frm start of graph to the 13:30 when test ended. ignore the in between part and rest graph that is of another ongoing test. On Thursday, January 23, 2014 7:06 PM, Mark Thomas ma...@apache.org wrote: On 23/01/2014 13:30, akshay hiremath wrote: Why tomcat is not able to have more than 200 active Threads (parallel threads) processng my requests? It can. The issue is that the combination of the requests you are making (which you fail to describe), your load testing framework (which you fail to describe) and the scheduling in the CPUs of your hardware (which you also fail to describe) mean that the chances of there actually being 300 concurrent requests for Tomcat to process is pretty much zero. Mark - 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
Re: Tomcat 7 not honoring maxThreads configuration in catalina.properties and activeCount not going beyond 200
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 akshay, On 1/23/14, 9:07 AM, akshay hiremath wrote: We have this HP load runner running a load of requests on this system. We don't see request rejected by Tomcat but if I monitor the activeCount attribute of Mbean Catalina:type=Executor,name=tomcatThreadPool over the period of test why the activeCount is not going above 200. if I continuously track activeCount and currentThreadsBusy of MBean Catalina:type=ThreadPool,name=http-bio-8080 I see the graph reahes 200 and flat lines there. Please find monitored graph attached during one of the tests. See time frm start of graph to the 13:30 when test ended. ignore the in between part and rest graph that is of another ongoing test. Attachments are stripped from the list. Find another way to express your thoughts. Is it possible that you are simply not generating enough load? If Tomcat is responding to all of your requests (e.g. none of them are failing to connect, failing to respond, or responding very slowly -- as if queued) than it sounds like your Tomcat instance is handling all the load you are throwing at it. - -chris On Thursday, January 23, 2014 7:06 PM, Mark Thomas ma...@apache.org wrote: On 23/01/2014 13:30, akshay hiremath wrote: Why tomcat is not able to have more than 200 active Threads (parallel threads) processng my requests? It can. The issue is that the combination of the requests you are making (which you fail to describe), your load testing framework (which you fail to describe) and the scheduling in the CPUs of your hardware (which you also fail to describe) mean that the chances of there actually being 300 concurrent requests for Tomcat to process is pretty much zero. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org mailto:users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org mailto:users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS4TH3AAoJEBzwKT+lPKRY1vQP/01g9bL731iYBYV9MQtDhLMJ LeBXfV2996qnpX2VftnltPGXq2V9/l93tjRMiDxrcaGIrdzebkzv+PegRdhIxto1 JeIJh9xBFKd+J/aWTmzDYLzE9/eGoGRW+R+G3MuqqBs3KSXaNbEDHtdB/5zzQ0Bj Ht7iWTvPyEkp3JeKBo/FM/nZG2cnBNwC+kNWkdzlOqPIWUVOPmbqQky2qkM86s+d 65trfkDDSkez1ws2bZJ42TbW3IR9Qv1H/YlMzMmr2BJpGUnTAIKwu0l+bD+kH8pT QQo7anuTpuygwsE30zO3FcgkwzTuPcccHTh0G1XvzCYFJJ+tnAa4h+0Z6GAu7q6E 5ltIyHZjp4KJoLulNFQfqlItjabi6XIUwwQk/Ob4pRpgfsORIwapusY1vFThwhJv m3M0fVgWmxCHc41ed+mMhUPewXqqv0iaXKj4oxuW9GSPfdlQ7wCECwcIR11K39aU Ff9dbEEFuT7yvKgQy589dsSycgydCONTS+4b/25stwR1VgxA2MlvhcF8LBNN3o8L kPefjrOQVGLAuwrSgBiAVsD9dNDis5UhQ0sdGUKoLSuI3HSy1KMANVUWjYmig4bP fUmhGlKiM9CknxUpDK/rdAGWUOQU06rXeWVitQ/2p42UQibtAhXuM+1ymw/v4zou SBh0nxrR6K0AVV8KhomP =TIpT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
mohan.radhakrish...@polarisft.com wrote: Yes. That is probably the capacity planning part that involves think time analysis and concurrency. What Were They Thinking: Modeling Think Times for Performance Testing Tom Wilson from Computer Measurement Group is what I plan to refer to. But don't know yet how to mine this from awstats. The Redhat link describes it like this MaxClients( 300 ) / ThreadsPerChild( 25 ) = Processes( 12 ) mod_jk default connection pool Each worker has a connection pool and by default the connection pool size is equal to ThreadsPerChild( 25 ) In the default case each worker has 25 connections multiplexed over 12 processes equaling 300. Two workers will have 300 x 2 =600 connections to Jboss. But I don't understand how one core with 2 hardware threads can support 200 threads. I don't get that calculation. And you are right in not understanding it, because there is no such calculation. 200 threads doing what ? printing Hello World or calculating the GDP of China ? The problem is that when I draw a throughput graph using think time analysis and concurrent connections estimate I have to use 800 threads for a 4-core system if we have only Apache there. Why do you not just forget about the cores. They are not really relevant here. For the last 30 years, computers have been doing time-sharing between multiple processes. That means that the same CPU can handle multiple processes running at the same time. Having more than one core just means that the same CPU can, at certain times, be processing more than one task at the same time. For all practical intents and purposes, it is basically the same as having one core that is twice (or 3, 4 times) as fast. What is important here is how many client requests your chosen architecture can process in any chosen amount of time. And that depends for 90% on your application(s). So take the default values for everything (because at least they are not severely unbalanced), and *measure* how your system is doing under load. If you are statisfied, leave it at that and do the same on another system. If you are not satisfied, /then/ is the time to start looking deeper. But then you'll be doing it with some basic numbers to compare against, and not in the dark like now. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
On 9/24/2013 12:11 AM, mohan.radhakrish...@polarisft.com wrote: Yes. That is probably the capacity planning part that involves think time analysis and concurrency. What Were They Thinking: Modeling Think Times for Performance Testing Tom Wilson from Computer Measurement Group is what I plan to refer to. But don't know yet how to mine this from awstats. The Redhat link describes it like this MaxClients( 300 ) / ThreadsPerChild( 25 ) = Processes( 12 ) mod_jk default connection pool Each worker has a connection pool and by default the connection pool size is equal to ThreadsPerChild( 25 ) In the default case each worker has 25 connections multiplexed over 12 processes equaling 300. Two workers will have 300 x 2 =600 connections to Jboss. But I don't understand how one core with 2 hardware threads can support 200 threads. I don't get that calculation. The problem is that when I draw a throughput graph using think time analysis and concurrent connections estimate I have to use 800 threads for a 4-core system if we have only Apache there. As Andre says, it all depends on what those threads are doing, and that in turn depends almost entirely on your application. In some cases, you might be able to support 800 threads per core, and in others 50 per core might be overloading it. You have to benchmark your application and figure out what (if anything) is limiting you. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [a bit OT] MaxClients and maxThreads
David kerber wrote: On 9/24/2013 12:11 AM, mohan.radhakrish...@polarisft.com wrote: Yes. That is probably the capacity planning part that involves think time analysis and concurrency. What Were They Thinking: Modeling Think Times for Performance Testing Tom Wilson from Computer Measurement Group is what I plan to refer to. But don't know yet how to mine this from awstats. The Redhat link describes it like this MaxClients( 300 ) / ThreadsPerChild( 25 ) = Processes( 12 ) mod_jk default connection pool Each worker has a connection pool and by default the connection pool size is equal to ThreadsPerChild( 25 ) In the default case each worker has 25 connections multiplexed over 12 processes equaling 300. Two workers will have 300 x 2 =600 connections to Jboss. But I don't understand how one core with 2 hardware threads can support 200 threads. I don't get that calculation. The problem is that when I draw a throughput graph using think time analysis and concurrent connections estimate I have to use 800 threads for a 4-core system if we have only Apache there. As Andre says, it all depends on what those threads are doing, and that in turn depends almost entirely on your application. In some cases, you might be able to support 800 threads per core, and in others 50 per core might be overloading it. You have to benchmark your application and figure out what (if anything) is limiting you. Mohan, /yet) another way of looking at this : you are never really overloading a core. A core works at a fixed speed, it executes basic instruction cycles at a speed which depends on the hardware clock of the system (2.3 Ghz etc..). What happens is that if there is only one runnable program thread, then all the available cycles of the core can be dedicated to that one thread, and the series of instructions to be executed for that one thread to provide the desired result (for example, a HTTP response by a Tomcat webapp) will terminate very quickly, and the response will be very fast. If on the other hand there are 200 runnable threads due to Tomcat webapps being triggered by 200 simultaneous client requests, then this core will time-share between these 200 threads, and each webapp response will take 200 times longer to finish, than in the previous case. And if there are 500 runnable threads and only one core, then each response will just take 500 times longer than if there was only one thread. And if there are 500 runnable threads and 2 cores available, then each response will possibly take only 250 times more time than if there was a single thread runnable. (And I say possibly because webapp threads most probably do not only require CPU cycles in order to provide a response; they probably also need memory and/or disk I/O, in which case having more or less cores is not the main element). And then, have a look at one of your systems, with top (if you are under Linux) or the Task Manager (under Windows), and look at how many processes are running, apart from Apache httpd and Tomcat. Well, all of those processes compete with httpd and Tomcat for the same cores (and the same memory and the same I/O bandwidth). So how would that ever combine with some preset figure of 200 Tomcat threads per core ? What about these other processes, do they not count ? Now that can all be fine. If you server receives 100 client requests per second, and each request basically needs 1.5 ms of system time (*) to complete, then in total over that second you have only used 100 x 1.5 ms = 150 ms of system time, and during the remaining 850 ms of that second, your system is idle and just doing nothing. If you increase this to 500 client requests per second, then you will be using 500 x 1.5 ms = 750 ms of system time every second, and you still have 250 ms available doing nothing. But if you increase this to 1000 requests per second, then you would need 1000 x 1.5 ms = 1.5 s second of system time every second, and then clearly you have a problem : only 666 of those client requests can be served in 1 second (1000 requests / 1.5 ms), so 334 requests will have to wait. If during the next second, there are only 200 requests coming in, then that is still fine : that next second of system time will be able to process 100 new requests + 334 delayed requests, and everything will still run smoothly, because there is some buffering in the system to absorb a temporary excess of requests. But if 1000 requests per second is a permanent occurrence, then you have some choices : - just decide that the clients have to wait - improve your application to take less time - or get a bigger system There is no magic formula which will tell you in advance at which point your *system* is going to be overloaded (symptom: clients complain because they have to wait too long; other symptoms : your top display shows a permanent 100% CPU time, or 100% I/O wait time, or 100% memory usage). You must benchmark and
Re: MaxClients and maxThreads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 9/24/13 7:47 AM, David kerber wrote: On 9/24/2013 12:11 AM, mohan.radhakrish...@polarisft.com wrote: Yes. That is probably the capacity planning part that involves think time analysis and concurrency. What Were They Thinking: Modeling Think Times for Performance Testing Tom Wilson from Computer Measurement Group is what I plan to refer to. But don't know yet how to mine this from awstats. The Redhat link describes it like this MaxClients( 300 ) / ThreadsPerChild( 25 ) = Processes( 12 ) mod_jk default connection pool Each worker has a connection pool and by default the connection pool size is equal to ThreadsPerChild( 25 ) In the default case each worker has 25 connections multiplexed over 12 processes equaling 300. Two workers will have 300 x 2 =600 connections to Jboss. But I don't understand how one core with 2 hardware threads can support 200 threads. I don't get that calculation. The problem is that when I draw a throughput graph using think time analysis and concurrent connections estimate I have to use 800 threads for a 4-core system if we have only Apache there. As Andre says, it all depends on what those threads are doing, and that in turn depends almost entirely on your application. Specifically, whether your application is CPU-bound or I/O bound. Most web applications that I have analyzed are almost entirely I/O bound: they spend most of their time waiting around for data to be ready (from a disk, network resource, database, etc.). This is why a 2-core CPU can handle 200 threads simultaneously: because at any given moment, only a few threads have anything worthwhile to do: the rest are sleeping waiting on an I/O event to occur. Run top on your server and watch the load average. Most *NIX systems define load average as the average length of the run-queue. The run-queue is the number of processes that are actively waiting for the CPU to give them time (e.g. they are runnable and not waiting on I/O). You'll see 3 numbers: usually the 1-minute average, the 5-minute average, and the 15-minute average. On my development server right now, those numbers are 1.82, 2.46, 2.18. That means that I have roughly 2 processes waiting in the run queue all the time. I have a 2-core machine (well, it's virtualized so the hypervisor is probably lying to me, but anyway...) so a run-queue of 2 is just about right. If the run queue starts to approach something like 2x the number of cores I have available, I have to consider whether an upgrade is in order. Run a load-test on your hardware and watch everything: load average, response times, etc. Response time is king, of course, but the load-average can give you some insight into how hard the server is actually working. If your response times are within your acceptable thresholds for usability, then look to the load average for a clue as to how much more load you might be able to take. If you have a 4-core machine and the load average is 2 (during a load test), then you can probably take a lot more load. Obviously, you must re-test with more load to confirm that you can sustain that kind of load instead of just guessing based upon a small load + favorable load average. In some cases, you might be able to support 800 threads per core, and in others 50 per core might be overloading it. You have to benchmark your application and figure out what (if anything) is limiting you. +1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSQZ8uAAoJEBzwKT+lPKRY2UwP/iGoU6rGZ1cyis7rhnevRwir bj/A3hY7XkpkOw30QrdGpbnu3qIZpPWn04rgjXjByWa1tBvheMs5+JSx8wVJoKdy NAP0eLnMRHejEyC3ysJJP1DbsLrZ5DYZG87jXIrCb+vbL52TdklwdB3zNSLskZ+N QuINAlHt/vFC/GwQSv6tATzuCNToKpR1BFUazw6sK+8D2QNjA98bLH2trK1Q2Vin vSOGUMOJUCWsY7QMZxVwfaWEiwaE52HUYZws0ocZzGmQBdoXaLiMYSmdsiJvlHB6 ITb108Qwp7n1CM5ImkWTLu+/lpFWBLisM896Uh6zcNXOAmj0XU0w0p/CCyVzq2Lz NN6GBzXOWsGC8UC8cR86bzq4EwGzQ9ck+8q3oocR/rEpIG+5BexjDcWHuuqZm9xz KITQnMOuZV/OCjX86SO0CB9gYY/yNTrGyHOIg3nKT49wdCTMhpMArm9rWcT9UKNl aM2rQDJQjTJG5Po5d6p9AAYcnxibjEJYRbzr0EHGGjhrPfsTOvFTYqBMLlrFDdZs qUTi7LiOyvQpuVEAbGZTZSwEQwpBI2Bu/GuzdlU6tGUoBvApkmKt+bxK0IeZ8EW9 pNZOK832W/y4Yd0sjKAb71DqYwR06JXZykqh8I2sTJHfOmAo4xA9GcRoJ0oeN/0g opS6qoWmKXsmQ6AjuicJ =+Lqr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
Yes. I understand the need for capacity planning. It probably involves concurrency, think time analysis etc. I was wondering if maxThreads and MaxClients are the same value. In a worker mpm MaxClients is the Apache setting and maxThreads is the JBoss setting. Moreover how does a figure of 200 for a core justified. So you mean that the figure of 200 is not based on any analysis. Thanks. From: Daniel Mikusa dmik...@gopivotal.com To: Tomcat Users List users@tomcat.apache.org Date: 09/20/2013 07:10 PM Subject:Re: MaxClients and maxThreads On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: Is this a hard limit ? No. So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. Don't base your performance tuning on values you found in an article online. The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application. By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many. Examine your needs, set the values you think will work and then load test to see how things perform. Adjust the settings further based on your load testing results. Dan I have this question. Does this mean that maxThreads and MaxClients should both be equal to each other ? My configuration is this. Machine 1 - JBoss and Apache(2 cores) Machine 2 - JBoss(2 cores) So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited by MaxClients in Machine 1 which should be only 200. Is that correct ? It is a bottleneck. Thanks, Mohan This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com
Re: MaxClients and maxThreads
Do not top-post. It makes it difficult to follow the conversation, who answers to what etc. From: Daniel Mikusa dmik...@gopivotal.com To: Tomcat Users List users@tomcat.apache.org Date: 09/20/2013 07:10 PM Subject:Re: MaxClients and maxThreads On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: Is this a hard limit ? No. So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. Don't base your performance tuning on values you found in an article online. The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application. By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many. Examine your needs, set the values you think will work and then load test to see how things perform. Adjust the settings further based on your load testing results. mohan.radhakrish...@polarisft.com wrote: Yes. I understand the need for capacity planning. It probably involves concurrency, think time analysis etc. I was wondering if maxThreads and MaxClients are the same value. In a worker mpm MaxClients is the Apache setting and maxThreads is the JBoss setting. In your kind of configuration, MaxClients are maxThreads are related, but they are not the same. They may be the same if every request received by Apache httpd is always transmitted to Tomcat. But then what would be the point of having httpd in front ? Moreover how does a figure of 200 for a core justified. So you mean that the figure of 200 is not based on any analysis. Exactly. Not all requests are equal, and not all applications are equal. And in processing a request, there is not only CPU time to take into account, there is memory, I/O etc. So who, other than you, can tell how many of *your* requests one core can handle in any amount of time ? It is ridiculous to provide such a number as if it was based on anything serious. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
23 sep 2013 09.00 André Warnier: Do not top-post. It makes it difficult to follow the conversation, who answers to what etc. From: Daniel Mikusa dmik...@gopivotal.com To: Tomcat Users List users@tomcat.apache.org Date: 09/20/2013 07:10 PM Subject:Re: MaxClients and maxThreads On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: And that was a top post you just posted.
Re: MaxClients and maxThreads
Who, moi ? MiB wrote: 23 sep 2013 09.00 André Warnier: Do not top-post. It makes it difficult to follow the conversation, who answers to what etc. From: Daniel Mikusa dmik...@gopivotal.com To: Tomcat Users List users@tomcat.apache.org Date: 09/20/2013 07:10 PM Subject:Re: MaxClients and maxThreads On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: And that was a top post you just posted. Yes, but it was difficult to do otherwise in this case, and it was a good illustration. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 9/21/13 9:53 AM, chris derham wrote: To add to what Daniel is saying, here is a little graphic representation, for one single client browser : (browser) -- HTTP -- (httpd + mod_jk) -- AJP -- (tomcat) -- (webapp) (1) | |- (local resources) (2) When the browser sends a request to httpd, one httpd child/thread is allocated to process that request and return a response to the client. That child/thread is busy with this one request, from the time the request is received to the time when the response has been sent. 2 cases are possible : a) the request is for something that can be served directly by httpd, without need to involve Tomcat. That is the (2) above. For example, in some configurations, static HTML pages, images, stylesheets etc. are served directly by httpd, and only requests for webapps are forwarded to Tomcat. b) the request is for something that has to be processed and served by Tomcat (the (1) above). In that case, httpd + mod_jk will forward the request to Tomcat, and wait for Tomcat's response. When Tomcat responds, httpd + mod_jk will return that response to the browser client. While Tomcat is processing that request, you have one Tomcat thread busy processing that request, and one httpd child/thread waiting for Tomcat to respond. So let's say that at the level of httpd, there are 1000 browser requests coming in every minute. The number of httpd children/threads needed to handle this, depends on how long it takes httpd, on average, to process each request. If it takes on average 1 second to process a request, then each httpd child/thread can on average process 60 requests per minute, and to handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads in httpd. Now estimate (or better, measure) how many of these requests are being forwarded to Tomcat, and how long Tomcat needs on average to process such a request and send a response. With the same kind of calculation, this will tell you how many threads you need in Tomcat. Now to be on the safe side, double these numbers (if your servers support that), and try it out, /with your application/, measure what happens, and rectify the configuration accordingly. The main point is : nobody except yourself knows exactly how your application works, how many requests are really served by httpd and tomcat, or how long it takes to process one request. So nobody can tell you in advance how many threads/children you need in httpd or Tomcat, to serve your volume of requests. The best that the Apache httpd developers, and the Tomcat developers can do, is to provide some best guess defaults, for some configuration that will, in their considerate opinion, be adequate for serving some average needs and not be very unbalanced. And that's what they do, and that is why you should generally start with this default configuration. And then, if you can see and *measure* that there is something wrong, start amending this configuration item by item carefully, and measure again after each change to see if it improves or worsens the situation. There is no one size fits all. (If there was, then the developers would just set it as the default, and they would not need to provide any adjustable parameters). This type of question seems to come up once every 3 months on the mailing list. Given that this is a beautiful explanation, perhaps we could add this as a new section to the tomcat documentation - a new Performance Tuning section? Anyone can edit the wiki -- after they request an account if one does not yet exist. Feel free to put-up a wiki page. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSQDYJAAoJEBzwKT+lPKRY57oP/jhjkeQMBrmnqzlX2f90Elfn 7ll3iBeYqaZnFrEdzWXuVLtSc4YgAXYvdZmI29MNv8dI+caXrj5oywecGo5w7nn5 Tl1+gk6MO8tqxjs8mY5NjiTRL+mD9dBLYIGbztlA15+5V3oSzPyop0ydlWjtu+uk 4Sj99JAq175rvPxJB/ob9LDX0sETnM4F1fXfoZz55OkYGzaMMxcHigbSTmckdrWr cvLwSGn2zjdYAOZW+nWEM7iVnCR4MMXJSskIo67i5wOy89vzmUjS0tt1fl38a4GW lkf/qVLPtI8qOboLNGW1b1d6zrqYJULXovfmqEZ3h9KTcvQ1SSI9nrCxfFZZ6x2F k5pGWCPXrlnwxP9fKswR1LgYz+y9KynHaFNH2wVaCqX6WdXzK5Vk+GtbJc/IBZHJ pNnw4UhFFGk87tiW3wofM5wcgBQpZbQRgfkBSJ14GN/nnYHovQMVmiK+VqsvMU3m oSCGdgyYFdfqdPqGvo5J//BMX9zg9t4mk8vkCpNlvFR9onvZD9TyDYh8/5Kjlnfb cv96n5xV/DiLGq7gUTFnXSFouXUDLhe9bCRnH7npkY2njZcodLRnaMopVdei/Xj1 V+6H30RniIMSEDyRBfq4Db/yvGeG9XGFsHY9wl6XxOj3btp62MDWKjLdYoJ7ECWX Mnb9lHGSaxAw/1BjiEpf =aYEa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 9/23/13 3:00 AM, André Warnier wrote: Do not top-post. It makes it difficult to follow the conversation, who answers to what etc. From: Daniel Mikusa dmik...@gopivotal.com To: Tomcat Users List users@tomcat.apache.org Date: 09/20/2013 07:10 PM Subject:Re: MaxClients and maxThreads On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: Is this a hard limit ? No. So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. Don't base your performance tuning on values you found in an article online. The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application. By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many. Examine your needs, set the values you think will work and then load test to see how things perform. Adjust the settings further based on your load testing results. mohan.radhakrish...@polarisft.com wrote: Yes. I understand the need for capacity planning. It probably involves concurrency, think time analysis etc. I was wondering if maxThreads and MaxClients are the same value. In a worker mpm MaxClients is the Apache setting and maxThreads is the JBoss setting. In your kind of configuration, MaxClients are maxThreads are related, but they are not the same. They may be the same if every request received by Apache httpd is always transmitted to Tomcat. But then what would be the point of having httpd in front ? Moreover how does a figure of 200 for a core justified. So you mean that the figure of 200 is not based on any analysis. Exactly. Not all requests are equal, and not all applications are equal. And in processing a request, there is not only CPU time to take into account, there is memory, I/O etc. So who, other than you, can tell how many of *your* requests one core can handle in any amount of time ? It is ridiculous to provide such a number as if it was based on anything serious. There is one more wrinkle, here, too. Suppose you have more than one fronting server running httpd and a single back-end server running Tomcat. If you have each of your front-end servers with 200 threads, that means its possible to have 400 simultaneous requests being sent to Tomcat. If Tomcat can't handle that many simultaneous requests, you'll get timeouts, disconnects, etc. The most pathological case is when you have N httpd instances and M Tomcat instances but M-1 Tomcat instances have failed and so N*MaxClients httpd requests are being sent to a single Tomcat instance. You just need to make sure you plan for that kind of situation and understand what will happen in those cases. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSQDcaAAoJEBzwKT+lPKRYOecQAJWY4H3BACTlBc9rApSZFd79 9xOz/2m7WGc45xRXsTED3katdtTu13ZkDxHB3iHK9jUzZ5LKlOE2npw9V7WaqyQF kQphbBcSIbG5fr5rWN73Hbt5laYOcSXdgSd1k7WyCjzThFre7zDeDy6A9GSXnzYI MH+C9Ddxy9wvujYdXnOACkXqck1vxJk19QlCGQrsWHYTdmmEEvahNYHjCSliaPVE Jz+Z/ZemP74fvi3RmFa9Mm350zyamnOvOEQeDTmwd87VxbvrRaRlAmuhnjSf16SA 4p94xF0Z1ppNbVnFoPL2qKQNmVDDXtbp7oTFpFtXa9Gc51KzGltP55y1zZqvTK+7 XmakjOpwRL6n/4xRBkuWKpCqXfzv+XTq8DPeHWfPeX3gWnbbZrbc4Dv+LlY/usyY to0uwQHsJ0aCzvLXfzMdXImGhCos09OpKE0f3RiAqRGJw+TdHZIFQJYiL92Lu37C 1Q5Nx1H7T4US6v8D9Ayl/6m7htj1wxOtqt00LxBXuNVJP1Y0sG3XzSZ1zW93eiSn ThfLKxKhmDhWWv4DYXHfZsWi+iueLM/zwthV8hiGtX9dcCvRndUhM2GViIHybP2O hBcqFQA7KZQu6f1JI2viIycw5kluQJNU/Iaugb/lNBMIuNKCEPv73K56aLnbycZF Ctvmo+SkUoYwMt2p29yi =c87Z -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
Yes. That is probably the capacity planning part that involves think time analysis and concurrency. What Were They Thinking: Modeling Think Times for Performance Testing Tom Wilson from Computer Measurement Group is what I plan to refer to. But don't know yet how to mine this from awstats. The Redhat link describes it like this MaxClients( 300 ) / ThreadsPerChild( 25 ) = Processes( 12 ) mod_jk default connection pool Each worker has a connection pool and by default the connection pool size is equal to ThreadsPerChild( 25 ) In the default case each worker has 25 connections multiplexed over 12 processes equaling 300. Two workers will have 300 x 2 =600 connections to Jboss. But I don't understand how one core with 2 hardware threads can support 200 threads. I don't get that calculation. The problem is that when I draw a throughput graph using think time analysis and concurrent connections estimate I have to use 800 threads for a 4-core system if we have only Apache there. Mohan From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Date: 09/23/2013 06:14 PM Subject:Re: MaxClients and maxThreads -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 9/23/13 3:00 AM, André Warnier wrote: Do not top-post. It makes it difficult to follow the conversation, who answers to what etc. From: Daniel Mikusa dmik...@gopivotal.com To: Tomcat Users List users@tomcat.apache.org Date: 09/20/2013 07:10 PM Subject:Re: MaxClients and maxThreads On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: Is this a hard limit ? No. So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. Don't base your performance tuning on values you found in an article online. The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application. By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many. Examine your needs, set the values you think will work and then load test to see how things perform. Adjust the settings further based on your load testing results. mohan.radhakrish...@polarisft.com wrote: Yes. I understand the need for capacity planning. It probably involves concurrency, think time analysis etc. I was wondering if maxThreads and MaxClients are the same value. In a worker mpm MaxClients is the Apache setting and maxThreads is the JBoss setting. In your kind of configuration, MaxClients are maxThreads are related, but they are not the same. They may be the same if every request received by Apache httpd is always transmitted to Tomcat. But then what would be the point of having httpd in front ? Moreover how does a figure of 200 for a core justified. So you mean that the figure of 200 is not based on any analysis. Exactly. Not all requests are equal, and not all applications are equal. And in processing a request, there is not only CPU time to take into account, there is memory, I/O etc. So who, other than you, can tell how many of *your* requests one core can handle in any amount of time ? It is ridiculous to provide such a number as if it was based on anything serious. There is one more wrinkle, here, too. Suppose you have more than one fronting server running httpd and a single back-end server running Tomcat. If you have each of your front-end servers with 200 threads, that means its possible to have 400 simultaneous requests being sent to Tomcat. If Tomcat can't handle that many simultaneous requests, you'll get timeouts, disconnects, etc. The most pathological case is when you have N httpd instances and M Tomcat instances but M-1 Tomcat instances have failed and so N*MaxClients httpd requests are being sent to a single Tomcat instance. You just need to make sure you plan for that kind of situation and understand what will happen in those cases. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSQDcaAAoJEBzwKT
Re: MaxClients and maxThreads
Daniel Mikusa wrote: On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: Is this a hard limit ? No. So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. Don't base your performance tuning on values you found in an article online. The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application. By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many. Examine your needs, set the values you think will work and then load test to see how things perform. Adjust the settings further based on your load testing results. Dan I have this question. Does this mean that maxThreads and MaxClients should both be equal to each other ? My configuration is this. Machine 1 - JBoss and Apache(2 cores) Machine 2 - JBoss(2 cores) So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited by MaxClients in Machine 1 which should be only 200. Is that correct ? It is a bottleneck. To add to what Daniel is saying, here is a little graphic representation, for one single client browser : (browser) -- HTTP -- (httpd + mod_jk) -- AJP -- (tomcat) -- (webapp) (1) | |- (local resources) (2) When the browser sends a request to httpd, one httpd child/thread is allocated to process that request and return a response to the client. That child/thread is busy with this one request, from the time the request is received to the time when the response has been sent. 2 cases are possible : a) the request is for something that can be served directly by httpd, without need to involve Tomcat. That is the (2) above. For example, in some configurations, static HTML pages, images, stylesheets etc. are served directly by httpd, and only requests for webapps are forwarded to Tomcat. b) the request is for something that has to be processed and served by Tomcat (the (1) above). In that case, httpd + mod_jk will forward the request to Tomcat, and wait for Tomcat's response. When Tomcat responds, httpd + mod_jk will return that response to the browser client. While Tomcat is processing that request, you have one Tomcat thread busy processing that request, and one httpd child/thread waiting for Tomcat to respond. So let's say that at the level of httpd, there are 1000 browser requests coming in every minute. The number of httpd children/threads needed to handle this, depends on how long it takes httpd, on average, to process each request. If it takes on average 1 second to process a request, then each httpd child/thread can on average process 60 requests per minute, and to handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads in httpd. Now estimate (or better, measure) how many of these requests are being forwarded to Tomcat, and how long Tomcat needs on average to process such a request and send a response. With the same kind of calculation, this will tell you how many threads you need in Tomcat. Now to be on the safe side, double these numbers (if your servers support that), and try it out, /with your application/, measure what happens, and rectify the configuration accordingly. The main point is : nobody except yourself knows exactly how your application works, how many requests are really served by httpd and tomcat, or how long it takes to process one request. So nobody can tell you in advance how many threads/children you need in httpd or Tomcat, to serve your volume of requests. The best that the Apache httpd developers, and the Tomcat developers can do, is to provide some best guess defaults, for some configuration that will, in their considerate opinion, be adequate for serving some average needs and not be very unbalanced. And that's what they do, and that is why you should generally start with this default configuration. And then, if you can see and *measure* that there is something wrong, start amending this configuration item by item carefully, and measure again after each change to see if it improves or worsens the situation. There is no one size fits all
Re: MaxClients and maxThreads
To add to what Daniel is saying, here is a little graphic representation, for one single client browser : (browser) -- HTTP -- (httpd + mod_jk) -- AJP -- (tomcat) -- (webapp) (1) | |- (local resources) (2) When the browser sends a request to httpd, one httpd child/thread is allocated to process that request and return a response to the client. That child/thread is busy with this one request, from the time the request is received to the time when the response has been sent. 2 cases are possible : a) the request is for something that can be served directly by httpd, without need to involve Tomcat. That is the (2) above. For example, in some configurations, static HTML pages, images, stylesheets etc. are served directly by httpd, and only requests for webapps are forwarded to Tomcat. b) the request is for something that has to be processed and served by Tomcat (the (1) above). In that case, httpd + mod_jk will forward the request to Tomcat, and wait for Tomcat's response. When Tomcat responds, httpd + mod_jk will return that response to the browser client. While Tomcat is processing that request, you have one Tomcat thread busy processing that request, and one httpd child/thread waiting for Tomcat to respond. So let's say that at the level of httpd, there are 1000 browser requests coming in every minute. The number of httpd children/threads needed to handle this, depends on how long it takes httpd, on average, to process each request. If it takes on average 1 second to process a request, then each httpd child/thread can on average process 60 requests per minute, and to handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads in httpd. Now estimate (or better, measure) how many of these requests are being forwarded to Tomcat, and how long Tomcat needs on average to process such a request and send a response. With the same kind of calculation, this will tell you how many threads you need in Tomcat. Now to be on the safe side, double these numbers (if your servers support that), and try it out, /with your application/, measure what happens, and rectify the configuration accordingly. The main point is : nobody except yourself knows exactly how your application works, how many requests are really served by httpd and tomcat, or how long it takes to process one request. So nobody can tell you in advance how many threads/children you need in httpd or Tomcat, to serve your volume of requests. The best that the Apache httpd developers, and the Tomcat developers can do, is to provide some best guess defaults, for some configuration that will, in their considerate opinion, be adequate for serving some average needs and not be very unbalanced. And that's what they do, and that is why you should generally start with this default configuration. And then, if you can see and *measure* that there is something wrong, start amending this configuration item by item carefully, and measure again after each change to see if it improves or worsens the situation. There is no one size fits all. (If there was, then the developers would just set it as the default, and they would not need to provide any adjustable parameters). This type of question seems to come up once every 3 months on the mailing list. Given that this is a beautiful explanation, perhaps we could add this as a new section to the tomcat documentation - a new Performance Tuning section? Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
Is this a hard limit ? So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Thanks, Mohan From: mohan.radhakrish...@polarisft.com To: users@tomcat.apache.org Date: 09/19/2013 05:56 PM Subject:MaxClients and maxThreads Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. I have this question. Does this mean that maxThreads and MaxClients should both be equal to each other ? My configuration is this. Machine 1 - JBoss and Apache(2 cores) Machine 2 - JBoss(2 cores) So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited by MaxClients in Machine 1 which should be only 200. Is that correct ? It is a bottleneck. Thanks, Mohan This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com
Re: MaxClients and maxThreads
On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: Is this a hard limit ? No. So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. Don't base your performance tuning on values you found in an article online. The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application. By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many. Examine your needs, set the values you think will work and then load test to see how things perform. Adjust the settings further based on your load testing results. Dan I have this question. Does this mean that maxThreads and MaxClients should both be equal to each other ? My configuration is this. Machine 1 - JBoss and Apache(2 cores) Machine 2 - JBoss(2 cores) So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited by MaxClients in Machine 1 which should be only 200. Is that correct ? It is a bottleneck. Thanks, Mohan This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
MaxClients and maxThreads
Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. I have this question. Does this mean that maxThreads and MaxClients should both be equal to each other ? My configuration is this. Machine 1 - JBoss and Apache(2 cores) Machine 2 - JBoss(2 cores) So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited by MaxClients in Machine 1 which should be only 200. Is that correct ? It is a bottleneck. Thanks, Mohan This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polarisFT.com
Re: Fw: Can not understand how maxThreads of Connectors works
I am using the correct server.xml.
In the version 5.5.36 the maxThreads of 0 has no effect due to this code in
org.apache.tomcat.util.net.PoolTcpEndpoint
public void setMaxThreads(int maxThreads) {
if( maxThreads 0)
tp.setMaxThreads(maxThreads);
}
So what I observe is correct. I.e. with 0 there is no error and also my web
application works fine since it defaults to 200 threads.
Will check this out in Tomcat 6
From: Christopher Schultz ch...@christopherschultz.net
To: Tomcat Users List users@tomcat.apache.org
Sent: Thursday, January 24, 2013 9:09 PM
Subject: Re: Fw: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 1/24/13 12:14 PM, André Warnier wrote:
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.
That last one is not true: the code will happily accept maxThreads=0
but then will throw an exception when the connector tries to actually
start its Executor.
I suspect Hermes is editing some unrelated server.xml file: his
observations seem totally in-line with that hypothesis.
Hermes, try modifying your server.xml file to be syntactically
incorrect. For example, put a !-- into the middle of the file and
try to start Tomcat. If it still starts, you are editing the wrong file.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEBhv8ACgkQ9CaO5/Lv0PDUWgCfWY/BUyhl4rQkZUC19SNB2P72
sckAn2dZwfEd7uVZz6eg0HuPmuZC81j6
=YVBj
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Can not understand how maxThreads of Connectors works
Hermes Flying wrote:
I am using the correct server.xml.
In the version 5.5.36 the maxThreads of 0 has no effect due to this code in
org.apache.tomcat.util.net.PoolTcpEndpoint
public void setMaxThreads(int maxThreads) {
if( maxThreads 0)
tp.setMaxThreads(maxThreads);
}
So what I observe is correct. I.e. with 0 there is no error and also my web
application works fine since it defaults to 200 threads.
Will check this out in Tomcat 6
On Jan 16, you wrote this :
Hermes Flying wrote:
Hi,
I am using Tomcat 6 (I think it is version 33 but will double check)
And JVM is Java 6 from IBM
Do you need exact versions?
And you haven't provided any other version number since then.
So why are you quoting Tomcat 5.5.36 code above ?
Do you actually enjoy confusing people on this list and causing them to uselessly spend
time answering your questions and trying to reproduce the symptoms which you indicate ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Can not understand how maxThreads of Connectors works
On Jan 16, you wrote this : Hermes Flying wrote: Hi, I am using Tomcat 6 (I think it is version 33 but will double check) And JVM is Java 6 from IBM Do you need exact versions? And you haven't provided any other version number since then. So why are you quoting Tomcat 5.5.36 code above ? Do you actually enjoy confusing people on this list and causing them to uselessly spend time answering your questions and trying to reproduce the symptoms which you indicate ? +1 The behaviour in 6.0.x is significantly different to that of 5.5.x. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/25/13 4:16 AM, Hermes Flying wrote: I am using the correct server.xml. In the version 5.5.36 the maxThreads of 0 has no effect due to this code in org.apache.tomcat.util.net.PoolTcpEndpoint You said you were using Tomcat 6. Now you say you are using Tomcat 5.5.36. This is why I asked (long ago) to give us exact versions. So what I observe is correct. I.e. with 0 there is no error and also my web application works fine since it defaults to 200 threads. Will check this out in Tomcat 6 Maybe then we'll finally be on the same page. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEC3kIACgkQ9CaO5/Lv0PBZUQCfWTYi3fmEi45N+wWGCVqz+yGf 4ZUAn1CdzM0CexovENDj3YJBhYCa1JIG =Gc1n -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Can not understand how maxThreads of Connectors works
Hi, I actually deploy in 2 servers one in 6 and one in 5. I noticed the same behavior described (that was not believed). I did not aim in taking anyone's time. All I wanted to do is verify the functionality using really small values. In a previous mail it was written by someone that he tested this in 6 and he said the browser stuck. I did not notice that. From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, January 25, 2013 9:34 PM Subject: Re: Fw: Can not understand how maxThreads of Connectors works -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/25/13 4:16 AM, Hermes Flying wrote: I am using the correct server.xml. In the version 5.5.36 the maxThreads of 0 has no effect due to this code in org.apache.tomcat.util.net.PoolTcpEndpoint You said you were using Tomcat 6. Now you say you are using Tomcat 5.5.36. This is why I asked (long ago) to give us exact versions. So what I observe is correct. I.e. with 0 there is no error and also my web application works fine since it defaults to 200 threads. Will check this out in Tomcat 6 Maybe then we'll finally be on the same page. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEC3kIACgkQ9CaO5/Lv0PBZUQCfWTYi3fmEi45N+wWGCVqz+yGf 4ZUAn1CdzM0CexovENDj3YJBhYCa1JIG =Gc1n -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Can not understand how maxThreads of Connectors works
On 25/01/2013 19:58, Hermes Flying wrote: Hi, I actually deploy in 2 servers one in 6 and one in 5. I noticed the same behavior described (that was not believed). I did not aim in taking anyone's time. All I wanted to do is verify the functionality using really small values. In a previous mail it was written by someone that he tested this in 6 and he said the browser stuck. I did not notice that. Exact Tomcat version. Exact connector configuration... This is getting tiresome. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
Re: Fw: Can not understand how maxThreads of Connectors works
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 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-- 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=2 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
Re: Fw: Can not understand how maxThreads of Connectors works
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
Re: Fw: Can not understand how maxThreads of Connectors works
Hi, I am sure that this server.xml is the one used, since there is no other present. Also as mentioned my plan is to cut network access after a threshold. I used such small values e.g. 0,1,2 to see what happens. Also note that I am not using SUN JVM but IBM. Not sure if this makes a difference From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 24, 2013 7:14 PM Subject: Re: Fw: Can not understand how maxThreads of Connectors works 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
Re: Fw: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/24/13 12:14 PM, André Warnier wrote: 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. That last one is not true: the code will happily accept maxThreads=0 but then will throw an exception when the connector tries to actually start its Executor. I suspect Hermes is editing some unrelated server.xml file: his observations seem totally in-line with that hypothesis. Hermes, try modifying your server.xml file to be syntactically incorrect. For example, put a !-- into the middle of the file and try to start Tomcat. If it still starts, you are editing the wrong file. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEBhv8ACgkQ9CaO5/Lv0PDUWgCfWY/BUyhl4rQkZUC19SNB2P72 sckAn2dZwfEd7uVZz6eg0HuPmuZC81j6 =YVBj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
On 25/01/2013, at 6:09 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/24/13 12:14 PM, André Warnier wrote: 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. That last one is not true: the code will happily accept maxThreads=0 but then will throw an exception when the connector tries to actually start its Executor. I suspect Hermes is editing some unrelated server.xml file: his observations seem totally in-line with that hypothesis. Hermes, try modifying your server.xml file to be syntactically incorrect. For example, put a !-- into the middle of the file and try to start Tomcat. If it still starts, you are editing the wrong file. And if using a Linux OS, you can use lsof to identify what file descriptors the tomcat JVM has opened, this is handy for tracking down issues with misplaced conf files. Cheers, Ben - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEBhv8ACgkQ9CaO5/Lv0PDUWgCfWY/BUyhl4rQkZUC19SNB2P72 sckAn2dZwfEd7uVZz6eg0HuPmuZC81j6 =YVBj -END PGP SIGNATURE- - 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
Re: Fw: Can not understand how maxThreads of Connectors works
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. From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 21, 2013 6:17 PM Subject: Re: Fw: Can not understand how maxThreads of Connectors works The web application works.I can not see any issue. What does this mean? From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 21, 2013 11:06 AM Subject: Re: Fw: Can not understand how maxThreads of Connectors works On 21/01/2013 07:07, Hermes Flying wrote: Hi, Is there any update on this? I don't see any problem setting maxThreads=0 And if you try making a request with a Tomcat instance that uses that configuration? Mark Thank you - Forwarded Message - From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, January 18, 2013 8:55 AM Subject: Re: Can not understand how maxThreads of Connectors works Hi Chris, Tried with this simple server.xml and maxThreads=0 but I did not see any kind of errors.Attached the catalina logs ?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=2 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
Re: Fw: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/23/13 5:25 PM, Hermes Flying wrote: 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. Sorry, but your description of what you experience does not match the experiences of others. The conclusion is that you are not configuring Tomcat the way you claim to be configuring it. You never told us what versions of things you were using. You never told us what OS you are on. You never told us how you are launching Tomcat. You never told us where your configuration files are. I cannot help you any further without the above information. I believe that others can also not help you without this information. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEAjhwACgkQ9CaO5/Lv0PCSNQCgjrNeg1OWsZvWRWVfqOCEWRmP LBsAn26IFVIG/5zXXofpNPnxEQXrFWD/ =XZvE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/21/13 11:17 AM, Hermes Flying wrote: The web application works.I can not see any issue. What does this mean? My guess is that Tomcat isn't using the configuration file you are modifying. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlD+p6sACgkQ9CaO5/Lv0PDy/gCfSagY1K29u8OpugO4plJ84s/y 7nsAn1IQSsFeH7F0mnaEnRMATmNkoKLD =Ioar -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Can not understand how maxThreads of Connectors works
On 21/01/2013 07:07, Hermes Flying wrote: Hi, Is there any update on this? I don't see any problem setting maxThreads=0 And if you try making a request with a Tomcat instance that uses that configuration? Mark Thank you - Forwarded Message - From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, January 18, 2013 8:55 AM Subject: Re: Can not understand how maxThreads of Connectors works Hi Chris, Tried with this simple server.xml and maxThreads=0 but I did not see any kind of errors.Attached the catalina logs ?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=2 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: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 17, 2013 6:57 PM Subject: Re: Can not understand how maxThreads of Connectors works -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/17/13 3:32 AM, André Warnier wrote: Quite a few messages ago, I asked the OP if he could copy/paste his server.xml. Yes. Getting information from the OP seems to be difficult. The reason was that if his config uses an Executor, then I believe the Threads settings
Re: Fw: Can not understand how maxThreads of Connectors works
The web application works.I can not see any issue. What does this mean? From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 21, 2013 11:06 AM Subject: Re: Fw: Can not understand how maxThreads of Connectors works On 21/01/2013 07:07, Hermes Flying wrote: Hi, Is there any update on this? I don't see any problem setting maxThreads=0 And if you try making a request with a Tomcat instance that uses that configuration? Mark Thank you - Forwarded Message - From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, January 18, 2013 8:55 AM Subject: Re: Can not understand how maxThreads of Connectors works Hi Chris, Tried with this simple server.xml and maxThreads=0 but I did not see any kind of errors.Attached the catalina logs ?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=2 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: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 17, 2013 6:57 PM Subject: Re: Can not understand how maxThreads of Connectors works -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Fw: Can not understand how maxThreads of Connectors works
Hi, Is there any update on this? I don't see any problem setting maxThreads=0 Thank you - Forwarded Message - From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, January 18, 2013 8:55 AM Subject: Re: Can not understand how maxThreads of Connectors works Hi Chris, Tried with this simple server.xml and maxThreads=0 but I did not see any kind of errors.Attached the catalina logs ?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=2 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: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 17, 2013 6:57 PM Subject: Re: Can not understand how maxThreads of Connectors works -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/17/13 3:32 AM, André Warnier wrote: Quite a few messages ago, I asked the OP if he could copy/paste his server.xml. Yes. Getting information from the OP seems to be difficult. The reason was that if his config uses an Executor, then I believe the Threads settings in the Connectors don't really matter, do they ? Correct: setting executor=someExecutor means that any executor-related settings on the Connector will be ignored in favor of those set in the Connector. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin
Re: Can not understand how maxThreads of Connectors works
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/16/13 3:07 PM, Hermes Flying wrote: I believe acceptCount can not work with value 0 because if I am not wrong, the acceptCount is the value passed as backlog in the ServerSocket constructor. According to javadoc if the backlog value is less than or equal to 0, then a default value is used instead which is 50. So acceptCount=0 does not mean that backlog queue does not queue anything. That is why I used the value 1 instead. Fair enough. Also when I say I was expecting a network failure (bad terminology) I meant that the client would get a failure in the TCP attempt to connect. Okay. Also I used maxThreads=0 and the server worked fine. Did not see any problem in my applications. Did not check the logs though. I assumed that perhaps 0 would be set to some default value. Can not answer about your observation. It also makes me wonder. Sure you can answer about my observation: look at your log files. Finally concerning my test setup, I need to configure Tomcat to limit the amount of concurrent client requests accepted. I understand that from reading your initial post. I need to configure it so that e.g. 300 concurrent clients can connect but the 301 will not be able to connect (not queued by OS either). That client will see a failure to connect to server in TCP level. I understand your requirements (though I think they are silly). Do you need more info on this? I was asking about your test setup. You said you made 2 simultaneous requests with what seems to be an effective throughput of 2 simultaneous requests (1 in-process and 1 in the queue) and were surprised that you got responses. I was not surprised. Are you still surprised? Next, how are you making those two simultaneous requests (specifically: like, are you using some tool to do it or did you write your own code)? What happens if you have maxThreads=1 and acceptCount=1 and you make 10 simultaneous requests? 100? Quite a few messages ago, I asked the OP if he could copy/paste his server.xml. The reason was that if his config uses an Executor, then I believe the Threads settings in the Connectors don't really matter, do they ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/17/13 3:32 AM, André Warnier wrote: Quite a few messages ago, I asked the OP if he could copy/paste his server.xml. Yes. Getting information from the OP seems to be difficult. The reason was that if his config uses an Executor, then I believe the Threads settings in the Connectors don't really matter, do they ? Correct: setting executor=someExecutor means that any executor-related settings on the Connector will be ignored in favor of those set in the Connector. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlD4LX4ACgkQ9CaO5/Lv0PAzegCgtxrX5Yx2V0UlEiDI1hK/vK+H u20AmwWQz6+LToA3uPSSb8V1+kdPMY3N =9fQb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
Hi, This is the server.xml. Sorry for not replying promptly but I am multitasking in a lot of things :( Server port=18085 shutdown=SHUTDOWN !-- Comment these entries out to disable JMX MBeans support used for the administration web application Listener className=org.apache.catalina.mbeans.ServerLifecycleListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ -- GlobalNamingResources 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 Service name=Catalina Connector port=8443 maxThreads=5000 acceptCount=2 enableLookups=false connectionTimeout=15 maxPostSize=1048576 redirectPort=-1 scheme=https sslProtocol=TLS clientAuth=false keystoreType=PKCS12 truststoreType=PKCS12 protocols=TLSv1 SSLImplementation=com.ssl.SSL_Implementation / Connector port=8444 maxThreads=5000 acceptCount=2 enableLookups=false connectionTimeout=15 maxPostSize=1048576 redirectPort=-1 scheme=https sslProtocol=TLS clientAuth=want keystoreType=PKCS12 truststoreType=PKCS12 protocols=TLSv1 SSLImplementation=com.ssl.SSL_Implementation_2 / Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false /Host /Engine /Service /Server From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 17, 2013 6:57 PM Subject: Re: Can not understand how maxThreads of Connectors works -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/17/13 3:32 AM, André Warnier wrote: Quite a few messages ago, I asked the OP if he could copy/paste his server.xml. Yes. Getting information from the OP seems to be difficult. The reason was that if his config uses an Executor, then I believe the Threads settings in the Connectors don't really matter, do they ? Correct: setting executor=someExecutor means that any executor-related settings on the Connector will be ignored in favor of those set in the Connector. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlD4LX4ACgkQ9CaO5/Lv0PAzegCgtxrX5Yx2V0UlEiDI1hK/vK+H u20AmwWQz6+LToA3uPSSb8V1+kdPMY3N =9fQb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
Hi Chris, Tried with this simple server.xml and maxThreads=0 but I did not see any kind of errors.Attached the catalina logs ?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=2 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: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 17, 2013 6:57 PM Subject: Re: Can not understand how maxThreads of Connectors works -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/17/13 3:32 AM, André Warnier wrote: Quite a few messages ago, I asked the OP if he could copy/paste his server.xml. Yes. Getting information from the OP seems to be difficult. The reason was that if his config uses an Executor, then I believe the Threads settings in the Connectors don't really matter, do they ? Correct: setting executor=someExecutor means that any executor-related settings on the Connector will be ignored in favor of those set in the Connector. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlD4LX4ACgkQ9CaO5/Lv0PAzegCgtxrX5Yx2V0UlEiDI1hK/vK+H u20AmwWQz6+LToA3uPSSb8V1+kdPMY3N =9fQb -END PGP SIGNATURE- - To unsubscribe, e
Re: Can not understand how maxThreads of Connectors works
Hermes Flying wrote: Hi, I am trying to understand how the maxThreads attribute of Connectors works. I did some tests in order to configure Tomcat to limit the number of concurrent client requests(as asked in my previous mail). Did the following trivial configuration. maxThreads=1 and acceptCount=1 Then I send 2 concurrent requests from 2 clients and both were served!I was expecting that one would get a network failure! I even tried maxThreads=0 and still the clients were served! How is this possible? Can you tell us which precise version of Tomcat you are using, with which precise JVM version, and also paste here a copy of your server.xml (any confidential information and comments removed) ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
Hi, I am using Tomcat 6 (I think it is version 33 but will double check) And JVM is Java 6 from IBM Do you need exact versions? From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, January 16, 2013 6:18 PM Subject: Re: Can not understand how maxThreads of Connectors works Hermes Flying wrote: Hi, I am trying to understand how the maxThreads attribute of Connectors works. I did some tests in order to configure Tomcat to limit the number of concurrent client requests(as asked in my previous mail). Did the following trivial configuration. maxThreads=1 and acceptCount=1 Then I send 2 concurrent requests from 2 clients and both were served!I was expecting that one would get a network failure! I even tried maxThreads=0 and still the clients were served! How is this possible? Can you tell us which precise version of Tomcat you are using, with which precise JVM version, and also paste here a copy of your server.xml (any confidential information and comments removed) ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
I apologize, You asked precise versions. Will let you know asap (don't remember them by heart) From: Hermes Flying flyingher...@yahoo.com To: Tomcat Users List users@tomcat.apache.org; Tomcat Users List users@tomcat.apache.org; a...@ice-sa.com a...@ice-sa.com Sent: Wednesday, January 16, 2013 6:29 PM Subject: Re: Can not understand how maxThreads of Connectors works Hi, I am using Tomcat 6 (I think it is version 33 but will double check) And JVM is Java 6 from IBM Do you need exact versions? From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, January 16, 2013 6:18 PM Subject: Re: Can not understand how maxThreads of Connectors works Hermes Flying wrote: Hi, I am trying to understand how the maxThreads attribute of Connectors works. I did some tests in order to configure Tomcat to limit the number of concurrent client requests(as asked in my previous mail). Did the following trivial configuration. maxThreads=1 and acceptCount=1 Then I send 2 concurrent requests from 2 clients and both were served!I was expecting that one would get a network failure! I even tried maxThreads=0 and still the clients were served! How is this possible? Can you tell us which precise version of Tomcat you are using, with which precise JVM version, and also paste here a copy of your server.xml (any confidential information and comments removed) ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/16/13 11:01 AM, Hermes Flying wrote: I am trying to understand how the maxThreads attribute of Connectors works. I did some tests in order to configure Tomcat to limit the number of concurrent client requests (as asked in my previous mail). Please copy anything relevant into this thread. Otherwise the archives don't work very well. Did the following trivial configuration. maxThreads=1 and acceptCount=1 Then I send 2 concurrent requests from 2 clients and both were served! I would expect both to be served: one request was served immediately (maxThreads=1) and one was queued (acceptCount=1). When the first request was completed, the second one came out of the queue and was served. If you had acceptCount=0 (which may or may not be legal for your TCP/IP stack) or you had sent 10 simultaneous connections, I would have expected at least some of them to be dropped with a connection error (assuming that they really are simultaneous and the response time is long enough to cover any variance in the connection-attempt time). Please provide more details about your test setup. I was expecting that one would get a network failure! Woah, you thought you'd take-down your network? You must be running some shaky hardware. I even tried maxThreads=0 and still the clients were served! How is this possible? maxThreads=0 is an illegal configuration. Are you sure Tomcat started properly? Tomcat 6+ uses an Executor whether you configure one of not, and the StandardThreadExecutor simply passes the maxThreads value off to Java's ThreadPoolExecutor, which will throw IllegalArgumentException if maxThreads is 0. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlD26OcACgkQ9CaO5/Lv0PCgLQCffw+xQflDLr4Ps8vYkQkcXUYw EZ0AoKU7bMkUJkmx21IgaRkNpQVV20dh =9xBW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
Hi Chris, thanks for the reply. Concerning your questions: I believe acceptCount can not work with value 0 because if I am not wrong, the acceptCount is the value passed as backlog in the ServerSocket constructor. According to javadoc if the backlog value is less than or equal to 0, then a default value is used instead which is 50. So acceptCount=0 does not mean that backlog queue does not queue anything. That is why I used the value 1 instead. Also when I say I was expecting a network failure (bad terminology) I meant that the client would get a failure in the TCP attempt to connect. Also I used maxThreads=0 and the server worked fine. Did not see any problem in my applications. Did not check the logs though. I assumed that perhaps 0 would be set to some default value. Can not answer about your observation.It also makes me wonder. Finally concerning my test setup, I need to configure Tomcat to limit the amount of concurrent client requests accepted. I need to configure it so that e.g. 300 concurrent clients can connect but the 301 will not be able to connect (not queued by OS either). That client will see a failure to connect to server in TCP level. Do you need more info on this? Best Regards From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, January 16, 2013 7:52 PM Subject: Re: Can not understand how maxThreads of Connectors works -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/16/13 11:01 AM, Hermes Flying wrote: I am trying to understand how the maxThreads attribute of Connectors works. I did some tests in order to configure Tomcat to limit the number of concurrent client requests (as asked in my previous mail). Please copy anything relevant into this thread. Otherwise the archives don't work very well. Did the following trivial configuration. maxThreads=1 and acceptCount=1 Then I send 2 concurrent requests from 2 clients and both were served! I would expect both to be served: one request was served immediately (maxThreads=1) and one was queued (acceptCount=1). When the first request was completed, the second one came out of the queue and was served. If you had acceptCount=0 (which may or may not be legal for your TCP/IP stack) or you had sent 10 simultaneous connections, I would have expected at least some of them to be dropped with a connection error (assuming that they really are simultaneous and the response time is long enough to cover any variance in the connection-attempt time). Please provide more details about your test setup. I was expecting that one would get a network failure! Woah, you thought you'd take-down your network? You must be running some shaky hardware. I even tried maxThreads=0 and still the clients were served! How is this possible? maxThreads=0 is an illegal configuration. Are you sure Tomcat started properly? Tomcat 6+ uses an Executor whether you configure one of not, and the StandardThreadExecutor simply passes the maxThreads value off to Java's ThreadPoolExecutor, which will throw IllegalArgumentException if maxThreads is 0. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlD26OcACgkQ9CaO5/Lv0PCgLQCffw+xQflDLr4Ps8vYkQkcXUYw EZ0AoKU7bMkUJkmx21IgaRkNpQVV20dh =9xBW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can not understand how maxThreads of Connectors works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hermes, On 1/16/13 3:07 PM, Hermes Flying wrote: I believe acceptCount can not work with value 0 because if I am not wrong, the acceptCount is the value passed as backlog in the ServerSocket constructor. According to javadoc if the backlog value is less than or equal to 0, then a default value is used instead which is 50. So acceptCount=0 does not mean that backlog queue does not queue anything. That is why I used the value 1 instead. Fair enough. Also when I say I was expecting a network failure (bad terminology) I meant that the client would get a failure in the TCP attempt to connect. Okay. Also I used maxThreads=0 and the server worked fine. Did not see any problem in my applications. Did not check the logs though. I assumed that perhaps 0 would be set to some default value. Can not answer about your observation. It also makes me wonder. Sure you can answer about my observation: look at your log files. Finally concerning my test setup, I need to configure Tomcat to limit the amount of concurrent client requests accepted. I understand that from reading your initial post. I need to configure it so that e.g. 300 concurrent clients can connect but the 301 will not be able to connect (not queued by OS either). That client will see a failure to connect to server in TCP level. I understand your requirements (though I think they are silly). Do you need more info on this? I was asking about your test setup. You said you made 2 simultaneous requests with what seems to be an effective throughput of 2 simultaneous requests (1 in-process and 1 in the queue) and were surprised that you got responses. I was not surprised. Are you still surprised? Next, how are you making those two simultaneous requests (specifically: like, are you using some tool to do it or did you write your own code)? What happens if you have maxThreads=1 and acceptCount=1 and you make 10 simultaneous requests? 100? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlD3DWcACgkQ9CaO5/Lv0PAwDwCdGGprLr1BEl3vueSsWcA3A7px kP0AoLq23hNN8sJkcHnFJQBx+2RwP/Ka =4dS/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: determining cause of MaxThreads exhausted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 4/13/12 4:40 PM, Miguel González Castaños wrote: The app sends massive emails to users with some info that requires users to log on the webapp and fill in some forms. It seems (without any logs or metrics) that people tend to fill the forms right away after they got the emails and together with the mailing process (that requires DB use to get email addresses) is exhausting the maxthreads connections (300 as of yesterday which I have increased to 400). Are you running out of request processors (Connector maxThreads) or are you running out of database connections (Resource maxActive)? MaxThreads Yes: log the timestamp of each access, then use one of the many fine web server analysis tools to get a picture (literally) of your volume. I have an access log with timestamps, which tool do you recommend to get an analysis? http://lmgtfy.com/?q=web+server+log+analysis - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+f91oACgkQ9CaO5/Lv0PB0oACePzOY8ojlBL03lj8WGCUSgGXb KOIAn2Rdpwi9t2UCr4DrkI25YWdIi+Tl =PbcW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
determining cause of MaxThreads exhausted
Dear all, A server that I manage has a Struts webapp with a Tomcat 5.5.x standalone server. No JMX or whatsoever has been configured. The app sends massive emails to users with some info that requires users to log on the webapp and fill in some forms. It seems (without any logs or metrics) that people tend to fill the forms right away after they got the emails and together with the mailing process (that requires DB use to get email addresses) is exhausting the maxthreads connections (300 as of yesterday which I have increased to 400). I assume it's not going to be easy to determine what is the cause of the issue but which tools can I use? I guess I need to log in some way how the server is behaving. Maybe enabling JMX or Javamelody? Any way of getting where the webapp is hanged or where in the code of the webapp is hanging? And which tool can help me to simulate the load of so many people connecting to the webapp remotely? Regards, Miguel This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: determining cause of MaxThreads exhausted
On 13 Apr 2012, at 09:09, Miguel González Castaños miguel_3_gonza...@yahoo.es wrote: Dear all, A server that I manage has a Struts webapp with a Tomcat 5.5.x standalone server. No JMX or whatsoever has been configured. The app sends massive emails to users with some info that requires users to log on the webapp and fill in some forms. It seems (without any logs or metrics) that people tend to fill the forms right away after they got the emails and together with the mailing process (that requires DB use to get email addresses) is exhausting the maxthreads connections (300 as of yesterday which I have increased to 400). How many emails does it send? I assume it's not going to be easy to determine what is the cause of the issue but which tools can I use? It might just be simple maths. If you send more than 400 emails and most of those people immediately respond, what would you expect to happen? I guess I need to log in some way how the server is behaving. Maybe enabling JMX or Javamelody? Any way of getting where the webapp is hanged or where in the code of the webapp is hanging? Access log? Enable JMX, use VisualVM/JConsole. And which tool can help me to simulate the load of so many people connecting to the webapp remotely? JMeter. p Regards, Miguel This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. - 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
Re: determining cause of MaxThreads exhausted
On 13/04/2012 10:14, Pid * wrote: On 13 Apr 2012, at 09:09, Miguel González Castaños miguel_3_gonza...@yahoo.es wrote: Dear all, A server that I manage has a Struts webapp with a Tomcat 5.5.x standalone server. No JMX or whatsoever has been configured. The app sends massive emails to users with some info that requires users to log on the webapp and fill in some forms. It seems (without any logs or metrics) that people tend to fill the forms right away after they got the emails and together with the mailing process (that requires DB use to get email addresses) is exhausting the maxthreads connections (300 as of yesterday which I have increased to 400). How many emails does it send? Around 1000 a minute I assume it's not going to be easy to determine what is the cause of the issue but which tools can I use? It might just be simple maths. If you send more than 400 emails and most of those people immediately respond, what would you expect to happen? I guess I need to log in some way how the server is behaving. Maybe enabling JMX or Javamelody? Any way of getting where the webapp is hanged or where in the code of the webapp is hanging? Access log? Enable JMX, use VisualVM/JConsole. Any way to use access log to get a view of how many visitors (not connections) we are getting? And which tool can help me to simulate the load of so many people connecting to the webapp remotely? JMeter. Any howto or article that explains of how to use JMeter in an environment like this? Miguel This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: determining cause of MaxThreads exhausted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 4/13/12 4:27 AM, Miguel González Castaños wrote: The app sends massive emails to users with some info that requires users to log on the webapp and fill in some forms. It seems (without any logs or metrics) that people tend to fill the forms right away after they got the emails and together with the mailing process (that requires DB use to get email addresses) is exhausting the maxthreads connections (300 as of yesterday which I have increased to 400). Are you running out of request processors (Connector maxThreads) or are you running out of database connections (Resource maxActive)? How many emails does it send? Around 1000 a minute I'm not sure the email volume has anything to do with the resource availability, other than an email may intise someone to go to your site, which will (temporarily) use up a request processor thread and (possibly) a database connection. Any way to use access log to get a view of how many visitors (not connections) we are getting? Yes: log the timestamp of each access, then use one of the many fine web server analysis tools to get a picture (literally) of your volume. Any howto or article that explains of how to use JMeter in an environment like this? JMeter is used virtually the same way in all environments: only you understand the nuances of your own software and can craft a load test that is appropriate for your application. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IjZsACgkQ9CaO5/Lv0PCtIQCgkZQncIn89KmLG5dvTyweJ90q xtYAn1aeBsx+W97Kx0sqeIq489HFFKXF =PKaP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: determining cause of MaxThreads exhausted
The app sends massive emails to users with some info that requires users to log on the webapp and fill in some forms. It seems (without any logs or metrics) that people tend to fill the forms right away after they got the emails and together with the mailing process (that requires DB use to get email addresses) is exhausting the maxthreads connections (300 as of yesterday which I have increased to 400). Are you running out of request processors (Connector maxThreads) or are you running out of database connections (Resource maxActive)? MaxThreads Yes: log the timestamp of each access, then use one of the many fine web server analysis tools to get a picture (literally) of your volume. I have an access log with timestamps, which tool do you recommend to get an analysis? Regards, Miguel This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Gotcha.. Thanks for your answer. Will let you know if i have any questions as we keep an eye on performance. Thanks -G From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 23, 2012 11:26 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 1/23/12 8:44 AM, gnath wrote: Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? Since you are using a thread pool, threads are probably expiring after a certain period of time. New threads get numbers that increase constantly over time, so you will see this number (in the name of the thread) increase over maxThreads. It's nothing to worry about. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8dtFAACgkQ9CaO5/Lv0PCdFwCdFF3NwnElEm6WaNAO7MOB3B5b LIYAoL9dfu+mULYAlt0oSDgUoV0oFZ2R =GkNd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6.0.35 -crossing maxThreads configured count
Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have two connectors (http and ssl) It has been giving some problems like 'too many open files' or just hangs once in a while which requires a restart to get back to normal. Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? Thanks -G
Re: Tomcat 6.0.35 -crossing maxThreads configured count
On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have two connectors (http and ssl) It has been giving some problems like 'too many open files' or just hangs once in a while which requires a restart to get back to normal. Have you taken any thread dumps when the server hangs? What do you see? Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? It would help to see how you have your thread pool and connectors configured. Please attach your server.xml minus any comments. Also, a thread dump would be nice to confirm how many threads were actually running. Dan
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). Which would be about 16 hours. I am not sure of the meaning of connectionTimeout in this context, but that value seems to me so large as to be pretty useless for any practical timeout I can imagine. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
On 23/01/2012 14:06, Daniel Mikusa wrote: On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have two connectors (http and ssl) It has been giving some problems like 'too many open files' or just hangs once in a while which requires a restart to get back to normal. Have you taken any thread dumps when the server hangs? What do you see? Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? It would help to see how you have your thread pool and connectors configured. Please attach your server.xml minus any comments. Also, a thread dump would be nice to confirm how many threads were actually running. The maxThreads in the Connector only applies to Tomcat request processing threads, it is not a limit imposed on the whole JVM. You will usually have 20-30 threads running doing various things in addition to those that your app starts. If Tomcat is at 500 + 20 then the rest are likely to be started by your application or dependencies. As Dan states, a thread dump is the way to understand this. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat 6.0.35 -crossing maxThreads configured count
André Warnier wrote: gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). Which would be about 16 hours. I am not sure of the meaning of connectionTimeout in this context, but that value seems to me so large as to be pretty useless for any practical timeout I can imagine. After checking the docs, that value is in milliseconds, not seconds : connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). That sounds more reasonable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Thanks Dan and p Sure, i will collect the thread dump once it happens again. Mean while here my server.xml content related to executor and connectors: Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 connectionTimeout=2 redirectPort=https port address=ip address/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=ip address keystoreFile=path to cert keystorePass=password / I understand what you are saying regarding the application owned threads, but do they show in the access logs with the prefix i mentioned for tomcatThreadPool (i saw in access logs as catalina-exec-770) ? Please let me know if im missing anything or doing anything wrong in my configuration. I will check on the thread dump once i collect it. Thanks -G From: Pid p...@pidster.com To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 23, 2012 6:12 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count On 23/01/2012 14:06, Daniel Mikusa wrote: On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have two connectors (http and ssl) It has been giving some problems like 'too many open files' or just hangs once in a while which requires a restart to get back to normal. Have you taken any thread dumps when the server hangs? What do you see? Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? It would help to see how you have your thread pool and connectors configured. Please attach your server.xml minus any comments. Also, a thread dump would be nice to confirm how many threads were actually running. The maxThreads in the Connector only applies to Tomcat request processing threads, it is not a limit imposed on the whole JVM. You will usually have 20-30 threads running doing various things in addition to those that your app starts. If Tomcat is at 500 + 20 then the rest are likely to be started by your application or dependencies. As Dan states, a thread dump is the way to understand this. p -- [key:62590808]
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Hi Andre, Sorry, my mistake. you are right. i actually meant milliseconds. However i checked my configuration again and here is what i have : ( I have the http connector configured at 2 ms. and the secured one left at default 6 ms) Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 connectionTimeout=2 redirectPort=https port address=ip address/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=ip address keystoreFile=path to cert keystorePass=password / Please let me know if im doing any mistake or missing anything here. Thanks -G From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 23, 2012 6:14 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count André Warnier wrote: gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). Which would be about 16 hours. I am not sure of the meaning of connectionTimeout in this context, but that value seems to me so large as to be pretty useless for any practical timeout I can imagine. After checking the docs, that value is in milliseconds, not seconds : connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). That sounds more reasonable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Hi Andre, Sorry, my mistake. you are right. i actually meant milliseconds. However i checked my configuration again and here is what i have : ( I have the http connector configured at 2 ms. and the secured one left at default 6 ms) Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 connectionTimeout=2 redirectPort=https port address=ip address/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=ip address keystoreFile=path to cert keystorePass=password / Please let me know if im doing any mistake or missing anything here. On the face of it, you are, or you are prone to typos. Assuming that when you indicate http port above, you mean that this is in reality some consistent specific valid port number, then at least one of them is wrong. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Please ignore my previously sent edited configuration. Here is what our configurations are without editing them : Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=40080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=40443 address=192.42.24.40/ Connector enableLookups=false executor=tomcatThreadPool port=40443 protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=192.42.24.40 keystoreFile=/usr/bin/keystore keystorePass=password / Please let me know. I appreciate your help in looking into this Thanks G From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 23, 2012 6:37 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count gnath wrote: Hi Andre, Sorry, my mistake. you are right. i actually meant milliseconds. However i checked my configuration again and here is what i have : ( I have the http connector configured at 2 ms. and the secured one left at default 6 ms) Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 connectionTimeout=2 redirectPort=https port address=ip address/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=ip address keystoreFile=path to cert keystorePass=password / Please let me know if im doing any mistake or missing anything here. On the face of it, you are, or you are prone to typos. Assuming that when you indicate http port above, you mean that this is in reality some consistent specific valid port number, then at least one of them is wrong. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
On Mon, 2012-01-23 at 06:24 -0800, gnath wrote: Thanks Dan and p Sure, i will collect the thread dump once it happens again. Mean while here my server.xml content related to executor and connectors: Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 connectionTimeout=2 redirectPort=https port address=ip address/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=ip address keystoreFile=path to cert keystorePass=password / I understand what you are saying regarding the application owned threads, but do they show in the access logs with the prefix i mentioned for tomcatThreadPool (i saw in access logs as catalina-exec-770) ? I do not believe that a thread with the name catalina-exec-770 means that there are 770 active threads. It means that the thread you are looking at is number 770. The 770 is just an identifier. From the docs for Executor: The name prefix for each thread created by the executor. The thread name for an individual thread will be namePrefix+threadNumber. You can get a count of the threads being used by your executor with the following command: jstack tomcat-pid | grep catalina-exec- | wc Dan Please let me know if im missing anything or doing anything wrong in my configuration. I will check on the thread dump once i collect it. Thanks -G From: Pid p...@pidster.com To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 23, 2012 6:12 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count On 23/01/2012 14:06, Daniel Mikusa wrote: On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have two connectors (http and ssl) It has been giving some problems like 'too many open files' or just hangs once in a while which requires a restart to get back to normal. Have you taken any thread dumps when the server hangs? What do you see? Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? It would help to see how you have your thread pool and connectors configured. Please attach your server.xml minus any comments. Also, a thread dump would be nice to confirm how many threads were actually running. The maxThreads in the Connector only applies to Tomcat request processing threads, it is not a limit imposed on the whole JVM. You will usually have 20-30 threads running doing various things in addition to those that your app starts. If Tomcat is at 500 + 20 then the rest are likely to be started by your application or dependencies. As Dan states, a thread dump is the way to understand this. p -- [key:62590808]
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Sure i will keep monitoring the Thread count as you said using jstack and keep you posted once the server hangs again. Thanks -G From: Daniel Mikusa dmik...@vmware.com To: Tomcat Users List users@tomcat.apache.org; gnath gautam_exquis...@yahoo.com Sent: Monday, January 23, 2012 6:44 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count On Mon, 2012-01-23 at 06:24 -0800, gnath wrote: Thanks Dan and p Sure, i will collect the thread dump once it happens again. Mean while here my server.xml content related to executor and connectors: Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 connectionTimeout=2 redirectPort=https port address=ip address/ Connector enableLookups=false executor=tomcatThreadPool port=http port protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=ip address keystoreFile=path to cert keystorePass=password / I understand what you are saying regarding the application owned threads, but do they show in the access logs with the prefix i mentioned for tomcatThreadPool (i saw in access logs as catalina-exec-770) ? I do not believe that a thread with the name catalina-exec-770 means that there are 770 active threads. It means that the thread you are looking at is number 770. The 770 is just an identifier. From the docs for Executor: The name prefix for each thread created by the executor. The thread name for an individual thread will be namePrefix+threadNumber. You can get a count of the threads being used by your executor with the following command: jstack tomcat-pid | grep catalina-exec- | wc Dan Please let me know if im missing anything or doing anything wrong in my configuration. I will check on the thread dump once i collect it. Thanks -G From: Pid p...@pidster.com To: Tomcat Users List users@tomcat.apache.org Sent: Monday, January 23, 2012 6:12 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count On 23/01/2012 14:06, Daniel Mikusa wrote: On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have two connectors (http and ssl) It has been giving some problems like 'too many open files' or just hangs once in a while which requires a restart to get back to normal. Have you taken any thread dumps when the server hangs? What do you see? Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? It would help to see how you have your thread pool and connectors configured. Please attach your server.xml minus any comments. Also, a thread dump would be nice to confirm how many threads were actually running. The maxThreads in the Connector only applies to Tomcat request processing threads, it is not a limit imposed on the whole JVM. You will usually have 20-30 threads running doing various things in addition to those that your app starts. If Tomcat is at 500 + 20 then the rest are likely to be started by your application or dependencies. As Dan states, a thread dump is the way to understand this. p -- [key:62590808]
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Please ignore my previously sent edited configuration. Here is what our configurations are without editing them : Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=40080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=40443 address=192.42.24.40/ Connector enableLookups=false executor=tomcatThreadPool port=40443 protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=192.42.24.40 keystoreFile=/usr/bin/keystore keystorePass=password / Please let me know. I appreciate your help in looking into this I have not gone back to your first message, but from the subject I guess that your concern is that you think that there are a lot of threads active in Tomcat, as compared to the number of HTTP requests that your server is receiving. The following does not in any way mean that you should not follow the other advices, and verify your assumptions, using the appropriate tools. But you may also want to have a look at the Connector's keep-alive setting. connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). keepAliveTimeout The number of milliseconds this Connector will wait for another HTTP request before closing the connection. The default value is to use the value that has been set for the connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout. In your configuration, you do not use an explicit keepAliveTimeout attribute, so it defaults to the connectionTimeout, which is 20 seconds. Imagine that your server receives requests for pages, at the rate of 10 per second. And that each page contains 3 embedded thumbnail images. So after the first request for the page, the browser is going to issue 3 more requests for the embedded images. By default, the keep-alive is active, which means that this all happens over the same HTTP (or HTTPS) connection; and since it all happens over the same established connection, it will also be processed by the same Tomcat thread. Which is all basically all A Good Thing, because it avoids having to tear down and rebuild connections and threads for each request. Processing the 4 consecutive requests of the browser is likely to take only a fraction of a second altogether. After these 4 requests are served, the keepAliveTimeout starts running, and with your current settings it does so for 20 seconds. During these 20 seconds, the thread which has processed the 4 requests keeps waiting, in case the browser has any more requests to send over the same connection (which it probably has not, because the user is considering his next move). 1/10th of a second after the first request, another browser also sends a request. Since the first thread is still busy, a new one is allocated. After a fraction of a second, that one goes in keepAliveTimeout. And so on. So all in all, this scenario is allocating new threads at the rythm of 10 per second; and it is only after the first 20 seconds have gone by, that the timeout of the first thread expires, that it can close its connection, and return to the pool to process another browser request. By that time, according to the above scenario, you have about 200 threads waiting in their keep-alive status, and basically not doing anything. I am not saying that your scenario matches the above, and only you can determine that. But it could explain a high number of threads apparently idle. So if those idle threads bother you, it may be worth trying an explicit lower keepAliveTimeout (e.g. 5 s), and monitor the impact. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Please ignore my previously sent edited configuration. Here is what our configurations are without editing them : Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=500 minSpareThreads=50/ Connector enableLookups=false executor=tomcatThreadPool port=40080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=40443 address=192.42.24.40/ Connector enableLookups=false executor=tomcatThreadPool port=40443 protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS address=192.42.24.40 keystoreFile=/usr/bin/keystore keystorePass=password / Please let me know. I appreciate your help in looking into this I have not gone back to your first message, but from the subject I guess that your concern is that you think that there are a lot of threads active in Tomcat, as compared to the number of HTTP requests that your server is receiving. The following does not in any way mean that you should not follow the other advices, and verify your assumptions, using the appropriate tools. But you may also want to have a look at the Connector's keep-alive setting. connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). keepAliveTimeout The number of milliseconds this Connector will wait for another HTTP request before closing the connection. The default value is to use the value that has been set for the connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout. In your configuration, you do not use an explicit keepAliveTimeout attribute, so it defaults to the connectionTimeout, which is 20 seconds. Imagine that your server receives requests for pages, at the rate of 10 per second. And that each page contains 3 embedded thumbnail images. So after the first request for the page, the browser is going to issue 3 more requests for the embedded images. By default, the keep-alive is active, which means that this all happens over the same HTTP (or HTTPS) connection; and since it all happens over the same established connection, it will also be processed by the same Tomcat thread. Which is all basically all A Good Thing, because it avoids having to tear down and rebuild connections and threads for each request. Processing the 4 consecutive requests of the browser is likely to take only a fraction of a second altogether. After these 4 requests are served, the keepAliveTimeout starts running, and with your current settings it does so for 20 seconds. During these 20 seconds, the thread which has processed the 4 requests keeps waiting, in case the browser has any more requests to send over the same connection (which it probably has not, because the user is considering his next move). 1/10th of a second after the first request, another browser also sends a request. Since the first thread is still busy, a new one is allocated. After a fraction of a second, that one goes in keepAliveTimeout. And so on. So all in all, this scenario is allocating new threads at the rythm of 10 per second; and it is only after the first 20 seconds have gone by, that the timeout of the first thread expires, that it can close its connection, and return to the pool to process another browser request. By that time, according to the above scenario, you have about 200 threads waiting in their keep-alive status, and basically not doing anything. I am not saying that your scenario matches the above, and only you can determine that. But it could explain a high number of threads apparently idle. So if those idle threads bother you, it may be worth trying an explicit lower keepAliveTimeout (e.g. 5 s), and monitor the impact. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 1/23/12 8:44 AM, gnath wrote: Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? Since you are using a thread pool, threads are probably expiring after a certain period of time. New threads get numbers that increase constantly over time, so you will see this number (in the name of the thread) increase over maxThreads. It's nothing to worry about. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8dtFAACgkQ9CaO5/Lv0PCdFwCdFF3NwnElEm6WaNAO7MOB3B5b LIYAoL9dfu+mULYAlt0oSDgUoV0oFZ2R =GkNd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: maxThreads
On 01/04/2011 06:58, Kaushal Shriyan wrote: Hi, What are the implications or issues if maxThreads are increased from the default 150 to 300 threads. Are there any performance issues ? Yes, may be at risk of improving performance. p I am using TC 5.5.27 , Ubuntu Linux Server 8.04 , Sun Java 1.6.0 Update 24 Please suggest/guide. Thanks and Regards, Kaushal signature.asc Description: OpenPGP digital signature
Re: maxThreads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 4/1/2011 6:43 AM, Pid wrote: On 01/04/2011 06:58, Kaushal Shriyan wrote: Hi, What are the implications or issues if maxThreads are increased from the default 150 to 300 threads. Are there any performance issues ? Yes, may be at risk of improving performance. Hah. Seriously, to the OP: if your webapp under load is not really using the CPU or network much (that is, you're waiting on some other resource) and still taking a long time to service requests, then increasing the number of connections is likely to /slow your webapp down/ because you will be putting more strain on those already-taxed resources. On the other hand, if your webapp under load is using a lot of CPU time, then you will also experience a slowdown because you'll end up with more context switches to service all those requests PLUS you'll have more load on the CPU doing actual work. Finally, increasing the maxThreads will increase your memory requirements for two reasons: first, you'll need a stack for each thread to use (see your JVM's default or command-line switches for what that per-thread memory requirement is) PLUS you'll need the amount of memory that a typical request (or particularly memory-heavy request, if you want to be really safe) will use FOR EACH THREAD. The best thing to do is to load test your webapp and see what point your webapp stops responding in a reasonable amount of time (to be determined by your own requirements). If your response time is very fast and your server is using very little CPU, then you can increase the maxThreads until things start to become intolerable. Oh, and if you are using Tomcat behind some web server like Apache httpd, you might want to make sure that your value for maxThreads matches whatever configuration you have on the web server so that you can actually serve that many requests through to Tomcat. ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2V6rAACgkQ9CaO5/Lv0PCNYQCfUQ+KKMvNUbbsgI2jQ8DgfeoF 90EAoMKOwBIwrcsuv8LZsC5sRkXajcj/ =JaTv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
maxThreads
Hi, What are the implications or issues if maxThreads are increased from the default 150 to 300 threads. Are there any performance issues ? I am using TC 5.5.27 , Ubuntu Linux Server 8.04 , Sun Java 1.6.0 Update 24 Please suggest/guide. Thanks and Regards, Kaushal
About maxThreads
Hi all users. I'm using Tomcat 6.0.29 and I have changed to maxThreads parameter to 300 from 200 and restart tomcat but I have still getting below error in catalina log. Could you please help me,why this parameter was not activated ? so what should i do for active this parameter ? If you help me,I will be happy. server.xml Connector port=8080 protocol=HTTP/1.1 server=NONE secure=true maxThreads=300 connectionTimeout=2 URIEncoding=UTF-8 / catalina.log Jan 28, 2011 10:43:16 AM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status
Re: About maxThreads
2011/1/31 Semih Gokalp sem...@hotmail.com: I'm using Tomcat 6.0.29 and I have changed to maxThreads parameter to 300 from 200 and restart tomcat but I have still getting below error in catalina log. server.xml Connector port=8080 protocol=HTTP/1.1 server=NONE secure=true maxThreads=300 connectionTimeout=2 URIEncoding=UTF-8 / 1) What connectors are you using? (What is printed in the logs when Tomcat starts?) 2) Jan 28 is several days ago. Are you sure that it is not an old message? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
About maxThreads
Hi all users. I'm using Tomcat 6.0.29 and I have changed to maxThreads parameter to 300 from 200 and restart tomcat but I have still getting below error in catalina log. Could you please help me,why this parameter was not activated ? so what should i do for active this parameter ? If you help me,I will be happy. server.xml Connector port=8080 protocol=HTTP/1.1 server=NONE secure=true maxThreads=300 connectionTimeout=2 URIEncoding=UTF-8 / catalina.log Jan 28, 2011 10:43:16 AM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status
RE: About maxThreads
Hi, Thanks for quick reply. 1) What connectors are you using? (What is printed in the logs when Tomcat starts?) I hope this is that you want output.The below output was printed in catalina.log when I start tomcat.If you want further informations,I can send. Jan 28, 2011 6:35:17 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Jan 28, 2011 6:35:17 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 3814 ms Jan 28, 2011 6:35:17 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Jan 28, 2011 6:35:17 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.29 Jan 28, 2011 6:35:17 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory fim PropertiesUtils.init() propFile : /data/config/fim/fim.properties AbandonedObjectPool is used (org.apache.commons.dbcp.AbandonedObjectPool@367c218e) LogAbandoned: true RemoveAbandoned: true RemoveAbandonedTimeout: 300 Est3DGate initing... Jan 28, 2011 6:35:34 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Jan 28, 2011 6:35:35 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:18001 Jan 28, 2011 6:35:35 AM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/694 config=null Jan 28, 2011 6:35:36 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 19050 ms 2) Jan 28 is several days ago. Are you sure that it is not an old message? Yes,I am sure tomcat restart time is older then ThreadPool logFull output time.You can check restart time from above. Thanks again. Date: Mon, 31 Jan 2011 13:31:20 +0300 Subject: Re: About maxThreads From: knst.koli...@gmail.com To: users@tomcat.apache.org 2011/1/31 Semih Gokalp sem...@hotmail.com: I'm using Tomcat 6.0.29 and I have changed to maxThreads parameter to 300 from 200 and restart tomcat but I have still getting below error in catalina log. server.xml Connector port=8080 protocol=HTTP/1.1 server=NONE secure=true maxThreads=300 connectionTimeout=2 URIEncoding=UTF-8 / 1) What connectors are you using? (What is printed in the logs when Tomcat starts?) 2) Jan 28 is several days ago. Are you sure that it is not an old message? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About maxThreads
Can you paste the /whole/ of your server.xml file (comments and private stuff removed) ? Paste it the message, do not send it as an attachment. And, how are you starting Tomcat, and on which platform is this ? Semih Gokalp wrote: Hi, Thanks for quick reply. 1) What connectors are you using? (What is printed in the logs when Tomcat starts?) I hope this is that you want output.The below output was printed in catalina.log when I start tomcat.If you want further informations,I can send. Jan 28, 2011 6:35:17 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Jan 28, 2011 6:35:17 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 3814 ms Jan 28, 2011 6:35:17 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Jan 28, 2011 6:35:17 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.29 Jan 28, 2011 6:35:17 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory fim PropertiesUtils.init() propFile : /data/config/fim/fim.properties AbandonedObjectPool is used (org.apache.commons.dbcp.AbandonedObjectPool@367c218e) LogAbandoned: true RemoveAbandoned: true RemoveAbandonedTimeout: 300 Est3DGate initing... Jan 28, 2011 6:35:34 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Jan 28, 2011 6:35:35 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:18001 Jan 28, 2011 6:35:35 AM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/694 config=null Jan 28, 2011 6:35:36 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 19050 ms 2) Jan 28 is several days ago. Are you sure that it is not an old message? Yes,I am sure tomcat restart time is older then ThreadPool logFull output time.You can check restart time from above. Thanks again. Date: Mon, 31 Jan 2011 13:31:20 +0300 Subject: Re: About maxThreads From: knst.koli...@gmail.com To: users@tomcat.apache.org 2011/1/31 Semih Gokalp sem...@hotmail.com: I'm using Tomcat 6.0.29 and I have changed to maxThreads parameter to 300 from 200 and restart tomcat but I have still getting below error in catalina log. server.xml Connector port=8080 protocol=HTTP/1.1 server=NONE secure=true maxThreads=300 connectionTimeout=2 URIEncoding=UTF-8 / 1) What connectors are you using? (What is printed in the logs when Tomcat starts?) 2) Jan 28 is several days ago. Are you sure that it is not an old message? - 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
Re: About maxThreads
2011/1/31 Semih Gokalp sem...@hotmail.com: I hope this is that you want output.The below output was printed in catalina.log when I start tomcat.If you want further informations,I can send. (...) Jan 28, 2011 6:35:34 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Jan 28, 2011 6:35:35 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:18001 Yes, that is what I wanted. Note, that you have two connectors (HTTP one on 8080 and AJP one on 18001). So it might be that that was AJP one whose thread pool was exhausted. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: About maxThreads
Thanks everbody for helps. Yes,we have two connector but we changed all apache ProxyPass settings to http from ajp but still some applications may be use ajp.I will check all of them and look again logs about ThreadPool logfull warning. If it is possible,how can i see real time maxThread value that was set for connectors ? Semih Gokalp Istanbul/Turkiye Date: Mon, 31 Jan 2011 15:18:37 +0300 Subject: Re: About maxThreads From: knst.koli...@gmail.com To: users@tomcat.apache.org 2011/1/31 Semih Gokalp sem...@hotmail.com: I hope this is that you want output.The below output was printed in catalina.log when I start tomcat.If you want further informations,I can send. (...) Jan 28, 2011 6:35:34 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Jan 28, 2011 6:35:35 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:18001 Yes, that is what I wanted. Note, that you have two connectors (HTTP one on 8080 and AJP one on 18001). So it might be that that was AJP one whose thread pool was exhausted. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About maxThreads
2011/1/31 Semih Gokalp sem...@hotmail.com: If it is possible,how can i see real time maxThread value that was set for connectors ? /manager/jmxproxy?qry=*%3Atype%3DThreadPool%2C* In Tomcat 6.0.30+ that will require a role of manager (deprecated) or of manager-jmx (new since 6.0.30). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: About maxThreads
Thanks for all useful information Konstantin. Date: Mon, 31 Jan 2011 16:07:16 +0300 Subject: Re: About maxThreads From: knst.koli...@gmail.com To: users@tomcat.apache.org 2011/1/31 Semih Gokalp sem...@hotmail.com: If it is possible,how can i see real time maxThread value that was set for connectors ? /manager/jmxproxy?qry=*%3Atype%3DThreadPool%2C* In Tomcat 6.0.30+ that will require a role of manager (deprecated) or of manager-jmx (new since 6.0.30). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat] Can I see if 'maxThreads' is exceeded?
On 29/11/2010 22:21, Sylvain Laurent wrote: On 29 nov. 2010, at 15:01, Mark Thomas wrote: On 29/11/2010 13:57, sol myr wrote: Hi, I'm new to Tomcat management, and would appreciate help on the 'maxThreads' property of the Http Connector: 1) Please tell if I understood correctly: Suppose I configure 'maxThreads=100', and 130 users try to simultaneously access my Tomcat - then 100 users will be served immediately, and the other 30 will be put on hold? Is this correct? Yes. 2) Is there a way to monitor how many users are 'put on hold' (e.g. 50 on the above example)? No. It happens too low down the network stack for Tomcat to be able to get this information. Mark, correct me if I'm wrong, but I believe that actually with an Executor, the acceptor thread still accepts requests and enqueues them in a queue which is unbounded by default. You can monitor the size of this queue with JMX (attribute queueSize on the Executor's thread pool). What you refered to is when the acceptor thread does not keepup, the OS enqueues new TCP connections attempts up to a maximum (100 by default for the http basic IO connector). Executors aren't used by default. I was referring to the tcp backlog. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Tomcat] Can I see if 'maxThreads' is exceeded?
Hi, I'm new to Tomcat management, and would appreciate help on the 'maxThreads' property of the Http Connector: 1) Please tell if I understood correctly: Suppose I configure 'maxThreads=100', and 130 users try to simultaneously access my Tomcat - then 100 users will be served immediately, and the other 30 will be put on hold? Is this correct? 2) Is there a way to monitor how many users are 'put on hold' (e.g. 50 on the above example)? Can I ask tomcat log this information? Or is this information exposed on the 'manager'? Or via JConsole? Thanks.
Re: [Tomcat] Can I see if 'maxThreads' is exceeded?
Sorry, correction: on section 2, I meant to say e.g. 30 on the above example (wrote '50' by mistake). Thanks again. --- On Mon, 11/29/10, sol myr solmy...@yahoo.com wrote: From: sol myr solmy...@yahoo.com Subject: [Tomcat] Can I see if 'maxThreads' is exceeded? To: users@tomcat.apache.org Date: Monday, November 29, 2010, 5:57 AM Hi, I'm new to Tomcat management, and would appreciate help on the 'maxThreads' property of the Http Connector: 1) Please tell if I understood correctly: Suppose I configure 'maxThreads=100', and 130 users try to simultaneously access my Tomcat - then 100 users will be served immediately, and the other 30 will be put on hold? Is this correct? 2) Is there a way to monitor how many users are 'put on hold' (e.g. 50 on the above example)? Can I ask tomcat log this information? Or is this information exposed on the 'manager'? Or via JConsole? Thanks.
Re: [Tomcat] Can I see if 'maxThreads' is exceeded?
On 29/11/2010 13:57, sol myr wrote: Hi, I'm new to Tomcat management, and would appreciate help on the 'maxThreads' property of the Http Connector: 1) Please tell if I understood correctly: Suppose I configure 'maxThreads=100', and 130 users try to simultaneously access my Tomcat - then 100 users will be served immediately, and the other 30 will be put on hold? Is this correct? Yes. 2) Is there a way to monitor how many users are 'put on hold' (e.g. 50 on the above example)? No. It happens too low down the network stack for Tomcat to be able to get this information. Can I ask tomcat log this information? No. Or is this information exposed on the 'manager'? Or via JConsole? No. No. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat] Can I see if 'maxThreads' is exceeded?
Mark Thomas wrote: On 29/11/2010 13:57, sol myr wrote: Hi, I'm new to Tomcat management, and would appreciate help on the 'maxThreads' property of the Http Connector: 1) Please tell if I understood correctly: Suppose I configure 'maxThreads=100', and 130 users try to simultaneously access my Tomcat - then 100 users will be served immediately, and the other 30 will be put on hold? Is this correct? Yes. 2) Is there a way to monitor how many users are 'put on hold' (e.g. 50 on the above example)? No. It happens too low down the network stack for Tomcat to be able to get this information. If you search Google for tcp listen queue size or tcp accept queue size (or SOMAXCONN), you will find more information about this. Depending on your O.S., there may exist utility programs allowing to display the current state for a given port/socket. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat] Can I see if 'maxThreads' is exceeded?
André and Mark - thanks very much for the quick replies. --- On Mon, 11/29/10, André Warnier a...@ice-sa.com wrote: From: André Warnier a...@ice-sa.com Subject: Re: [Tomcat] Can I see if 'maxThreads' is exceeded? To: Tomcat Users List users@tomcat.apache.org Date: Monday, November 29, 2010, 6:21 AM Mark Thomas wrote: On 29/11/2010 13:57, sol myr wrote: Hi, I'm new to Tomcat management, and would appreciate help on the 'maxThreads' property of the Http Connector: 1) Please tell if I understood correctly: Suppose I configure 'maxThreads=100', and 130 users try to simultaneously access my Tomcat - then 100 users will be served immediately, and the other 30 will be put on hold? Is this correct? Yes. 2) Is there a way to monitor how many users are 'put on hold' (e.g. 50 on the above example)? No. It happens too low down the network stack for Tomcat to be able to get this information. If you search Google for tcp listen queue size or tcp accept queue size (or SOMAXCONN), you will find more information about this. Depending on your O.S., there may exist utility programs allowing to display the current state for a given port/socket. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat] Can I see if 'maxThreads' is exceeded?
On 29 nov. 2010, at 15:01, Mark Thomas wrote: On 29/11/2010 13:57, sol myr wrote: Hi, I'm new to Tomcat management, and would appreciate help on the 'maxThreads' property of the Http Connector: 1) Please tell if I understood correctly: Suppose I configure 'maxThreads=100', and 130 users try to simultaneously access my Tomcat - then 100 users will be served immediately, and the other 30 will be put on hold? Is this correct? Yes. 2) Is there a way to monitor how many users are 'put on hold' (e.g. 50 on the above example)? No. It happens too low down the network stack for Tomcat to be able to get this information. Mark, correct me if I'm wrong, but I believe that actually with an Executor, the acceptor thread still accepts requests and enqueues them in a queue which is unbounded by default. You can monitor the size of this queue with JMX (attribute queueSize on the Executor's thread pool). What you refered to is when the acceptor thread does not keepup, the OS enqueues new TCP connections attempts up to a maximum (100 by default for the http basic IO connector). Can I ask tomcat log this information? No. Or is this information exposed on the 'manager'? Or via JConsole? No. No. No. yes (executor queueSize) Sylvain - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 5.5.0 issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott, On 8/24/2010 12:12 PM, Scott Hamilton wrote: You've got two connectors in that server.xml, and one of them is AJP without any real other configuration parameters. If memory serves the thread limit when not specified for a connector is 200... +1 Can we assume you're using apache as a web server connecting to tomcat? Yeah, he said that in his original original post. What are you using there - mod_proxy_ajp? Mod_jk? What do the settings for that look like? Still waiting on that information. Also, if the OP is still using 5.5.0, it's really time to upgrade to 5.5.30. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1aIYACgkQ9CaO5/Lv0PChmwCdFwQ6er/fHTlqh/cWJO1iFL2B eokAoKXrouSEhmYX2xBtN3PdipZiXSl1 =oDcC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache 5.x issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
I have an issue where my Tomcat server is going down quite often with the following message: Aug 19, 2010 12:03:21 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status Aug 20, 2010 4:47:20 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-9602 Aug 20, 2010 4:47:21 PM org.apache.catalina.core.StandardService stop INFO: Stopping service website Aug 20, 2010 4:47:21 PM org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-9602 The curious thing is My MaxTrheads settings are set to 100 instead 200 as the snippet says, so I wonder from where Apache is taking this 200 I suppose this might be a hardcoded message but I need you to confirm that apache is reading my xml or not. Server.website.xml Connector port=9602 maxThreads=100 maxSpareThreads=50 minSpareThreads=10/ Please let me know whether you have information about this issue and if there's any workaround/hotfix/release where I could get this working. Thanks in advance. [reply] [-]Comment 1Mark Thomas 2010-08-24 10:16:16 ED Federico White Technical Support Specialist - Global Remote Services AVAYA | Lavalle 1877 - 7th Floor - C1051ABA | Voice US 720-444-0540| C1051ABA | Buenos Aires - Argentina - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Apache 5.x issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
From: White, Federico (Federico) [mailto:whi...@avaya.com] Subject: Apache 5.x issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads First off, it's not Apache 5.x, it's Tomcat 5.x. The term Apache refers to the Apache Software Foundation, for which Tomcat is just one of many products. Tell us your exact Tomcat version, the JVM level, the platform you're running on, whether or not you're using APR, and how you start Tomcat. Server.website.xml That's not an interesting file, since Tomcat doesn't use that name. Post the conf/server.xml file that Tomcat is using, preferably with comments stripped out and privileged information obfuscated. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache Tomcat 5.5.0 issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
Hi again, Since my first email might have not be that clear I'll re phrase it, I'm currently running a Tomcat webserver for an application that my company uses. It run's on windows server 2003, and the startup command was customized for our application and is the following C:\ProgramFiles\Avaya\IC71\tomcat\bin\tomcat5.exe//RS//AvayaICWebManag ement71 I really don't know what's the JVM level and the meaning for APR (if its really important kindly let me know how to get it and I will) We use a customized .xml file created for our product and this is the content (note we don't have the out of the box server.xml file) ?xml version=1.0 encoding=ISO-8859-1? Server port=8006 shutdown=SHUTDOWN Service name=website Connector port=9602 maxThreads=100 maxSpareThreads=50 minSpareThreads=10/ Connector port=9642 protocol=AJP/1.3 / Engine name=Catalina defaultHost=localhost Host name=localhost appBase=../comp autoDeploy=false Context docBase=C:\Program Files\Avaya\IC71/comp/website path=/website reloadable=false crossContext=true / /Host /Engine /Service /Server Thanks -Original Message- From: White, Federico (Federico) Sent: Martes, 24 de Agosto de 2010 12:09 p.m. To: 'users@tomcat.apache.org'; 'users-h...@tomcat.apache.org' Subject: Apache 5.x issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads I have an issue where my Tomcat server is going down quite often with the following message: Aug 19, 2010 12:03:21 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status Aug 20, 2010 4:47:20 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-9602 Aug 20, 2010 4:47:21 PM org.apache.catalina.core.StandardService stop INFO: Stopping service website Aug 20, 2010 4:47:21 PM org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-9602 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Apache Tomcat 5.5.0 issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
You've got two connectors in that server.xml, and one of them is AJP without any real other configuration parameters. If memory serves the thread limit when not specified for a connector is 200... Can we assume you're using apache as a web server connecting to tomcat? What are you using there - mod_proxy_ajp? Mod_jk? What do the settings for that look like? -Original Message- From: White, Federico (Federico) [mailto:whi...@avaya.com] Sent: Tuesday, August 24, 2010 11:44 AM To: users@tomcat.apache.org Subject: Apache Tomcat 5.5.0 issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads Hi again, Since my first email might have not be that clear I'll re phrase it, I'm currently running a Tomcat webserver for an application that my company uses. It run's on windows server 2003, and the startup command was customized for our application and is the following C:\ProgramFiles\Avaya\IC71\tomcat\bin\tomcat5.exe//RS//AvayaICWebManag ement71 I really don't know what's the JVM level and the meaning for APR (if its really important kindly let me know how to get it and I will) We use a customized .xml file created for our product and this is the content (note we don't have the out of the box server.xml file) ?xml version=1.0 encoding=ISO-8859-1? Server port=8006 shutdown=SHUTDOWN Service name=website Connector port=9602 maxThreads=100 maxSpareThreads=50 minSpareThreads=10/ Connector port=9642 protocol=AJP/1.3 / Engine name=Catalina defaultHost=localhost Host name=localhost appBase=../comp autoDeploy=false Context docBase=C:\Program Files\Avaya\IC71/comp/website path=/website reloadable=false crossContext=true / /Host /Engine /Service /Server Thanks -Original Message- From: White, Federico (Federico) Sent: Martes, 24 de Agosto de 2010 12:09 p.m. To: 'users@tomcat.apache.org'; 'users-h...@tomcat.apache.org' Subject: Apache 5.x issue - SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads I have an issue where my Tomcat server is going down quite often with the following message: Aug 19, 2010 12:03:21 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads (200) or check the servlet status Aug 20, 2010 4:47:20 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-9602 Aug 20, 2010 4:47:21 PM org.apache.catalina.core.StandardService stop INFO: Stopping service website Aug 20, 2010 4:47:21 PM org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-9602 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
