Re: maxThreads
On Mon, 10 May 2004, Hollerman Geralyn M wrote: | Evidently, I'm misunderstanding something about the maxThreads attribute | on the HTTP Connector; I saw from the docs that in Tomcat 5.0.19, this | is the maximum number of request processing threads to be created by | this connector. So, what that said to me was that if I wanted to allow | lots of requests, I ought to make that number larger than the default, | which the docs say is 200. I also assumed that this attribute, | maxThreads, is similar to the maxProcessors attribute that was used | in, for instance, Tomcat 4.0.4. When we were using Tomcat 4.0.4, we | often got the message No processor available, rejecting this | connection, and the way I was told to correct that error was to | increase maxProcessors, and this worked fine. But to correct another | problem, we were told to upgrade to 4.1.24, and then to 5.0.16. | The new tomcat code have (finally!) an idea of connection queues, so that you can have 2 processors, but 1 queue-entries, and you won't get the connection refused crap message, but instead the connectin will be queued untill a processor is available. This is possible due to the way TCP works - one thread can keep on receiving connections, but not handle them and instead stack them into a queue - then there's another thread dispatching this queue to the workers/processors as they become available. (Not that this is exactly as tomcat have done it, but this is the general idea) Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maxThreads
Hi, The new tomcat code have (finally!) an idea of connection queues, so that You just manage to hit a nerve with almost every post ;) This stuff has been in tomcat code for years, it's not new. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maxThreads
On Wed, 12 May 2004, Shapira, Yoav wrote: | | Hi, | | The new tomcat code have (finally!) an idea of connection queues, so | that | | You just manage to hit a nerve with almost every post ;) I don't have a trace of an idea of what you mean! ;) | This stuff has been in tomcat code for years, it's not new. It wasn't there in earlier Tomcat 4s (-at least- not in 3.2), as Craig didn't see the use for it. I rather clearly remember arguing rather heavily for this some years ago, yes. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maxThreads
Hi, It wasn't there in earlier Tomcat 4s (-at least- not in 3.2), as Craig didn't see the use for it. I rather clearly remember arguing rather heavily for this some years ago, yes. It was there in tomcat 4.0.1 and later. For tomcat 3.x I don't know but I believe you do. I'm glad you argued for this feature, as it's indeed important, and I'm glad Craig and others listened to you ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maxThreads
At 03:03 AM 5/11/2004 +, Bill Barker wrote: By default, Tomcat will start maxThreads/2 threads incase it needs lots of threads in a hurry. Almost all of them will be blocked, so there generally isn't that much OS overhead in creating them. However, if you set the 'maxSpareThreads' attribute on the connector, then you can keep Tomcat down to a relatively small number of threads unless it actually has to handle a large number of requests. Ok, so if my maxThreads is 1000, at startup there will be 500 threads created? I thought it just created the number in minSpareThreads and built on that, no? In the situation we're using Tomcat, there will be a large number of requests - for about the next week, as students get their grades - and then things will calm down somewhat. Our system is forever exceeding maxThreads, and all increasing that attribute does is make the system exceed it faster. That doesn't seem correct. Lynn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maxThreads
Hollerman Geralyn M [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Evidently, I'm misunderstanding something about the maxThreads attribute on the HTTP Connector; I saw from the docs that in Tomcat 5.0.19, this is the maximum number of request processing threads to be created by this connector. So, what that said to me was that if I wanted to allow lots of requests, I ought to make that number larger than the default, which the docs say is 200. I also assumed that this attribute, maxThreads, is similar to the maxProcessors attribute that was used in, for instance, Tomcat 4.0.4. When we were using Tomcat 4.0.4, we often got the message No processor available, rejecting this connection, and the way I was told to correct that error was to increase maxProcessors, and this worked fine. But to correct another problem, we were told to upgrade to 4.1.24, and then to 5.0.16. However, I have noticed that with maxThreads, if I increase the value, the number of threads I see on a Solaris 8 system grows quickly, like it's trying to meet whatever limit I set; it's as if I make that value larger, thinking that that increase is what Tomcat needs, the number of threads gets to that limit quicker. This can't be right. What am I missing? By default, Tomcat will start maxThreads/2 threads incase it needs lots of threads in a hurry. Almost all of them will be blocked, so there generally isn't that much OS overhead in creating them. However, if you set the 'maxSpareThreads' attribute on the connector, then you can keep Tomcat down to a relatively small number of threads unless it actually has to handle a large number of requests. Thanks! -- Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maxThreads
The first thing you need is a thread dump of the Tomcat process at the time you are experiencing all threads busy. You are 100% correct in your assumption that raising maxThreads will just delay the inevitable. Once you have a thread dump you can investigate what section of code has all of your threads blocked. Until then it's all just speculation... -chris -Original Message- From: Geralyn M Hollerman [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 10:42 AM To: Tomcat Users List Subject: maxThreads I am getting this message in my catalina.out file: SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status500 500; I have no idea why all threads would be busy and waiting. In the standard distribution of Tomcat 4.1.24, the value of maxThreads is 75; this number (in the Connector element would cause Tomcat to shut down after a couple of hours on my moderately busy server. It was suggested to me that I raise this value, but all it appears to have done is delay the inevitable stopping of Tomcat once all the threads were busy and waiting; but I thought that Tomcat recycled threads, no? What are the threads waiting for to tell them to stop waiting? How can I get them to move on? Thanks! -- Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maxThreads
Running against a database? Are you pooling the connections? We hit maxthreads when either the DB is messed up (i.e., someone locks a table) or before, when the programmers forgot to run socket_close() on the DB connection, thereby returning it to the pool. HTH, Ben Ricker On Mon, 2003-08-18 at 09:42, Geralyn M Hollerman wrote: I am getting this message in my catalina.out file: SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status500 500; I have no idea why all threads would be busy and waiting. In the standard distribution of Tomcat 4.1.24, the value of maxThreads is 75; this number (in the Connector element would cause Tomcat to shut down after a couple of hours on my moderately busy server. It was suggested to me that I raise this value, but all it appears to have done is delay the inevitable stopping of Tomcat once all the threads were busy and waiting; but I thought that Tomcat recycled threads, no? What are the threads waiting for to tell them to stop waiting? How can I get them to move on? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maxThreads
Ben Ricker wrote: Running against a database? Are you pooling the connections? We hit maxthreads when either the DB is messed up (i.e., someone locks a table) or before, when the programmers forgot to run socket_close() on the DB connection, thereby returning it to the pool. Why, yes I am going against a database - we could never get Tomcat connection pooling working right with it, so we went with just internal (Ingres db) connection pooling. I don't know a whole lot about that, as that's not the primary app I work on - it's kind of been just there, if you know what I mean, but now that you mention it, I think someone might be able to lock a table - I'll have to look into that. Forgive me for showing my ignorance, but is socket_close() a Java routine? I don't think I've seen that before - we probably call it something different. Is it anything like invalidating a session? -- Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maxThreads
On Mon, 2003-08-18 at 12:50, Geralyn M Hollerman wrote: Ben Ricker wrote: Running against a database? Are you pooling the connections? We hit maxthreads when either the DB is messed up (i.e., someone locks a table) or before, when the programmers forgot to run socket_close() on the DB connection, thereby returning it to the pool. Why, yes I am going against a database - we could never get Tomcat connection pooling working right with it, so we went with just internal (Ingres db) connection pooling. I don't know a whole lot about that, as that's not the primary app I work on - it's kind of been just there, if you know what I mean, but now that you mention it, I think someone might be able to lock a table - I'll have to look into that. Forgive me for showing my ignorance, but is socket_close() a Java routine? I don't think I've seen that before - we probably call it something different. Is it anything like invalidating a session? socket_close() is a Unix system call...just a bit of jargon on the admin side. I myself am not a programmer, so I do not know what the exact method in Java is. An easy way to figure out if it is database connections not being closed is to check the connections from the Tomcat server to the database (if you are admin) or, if you have the access, check the jdbc (or odbc) connections used on the database. There should not be more then 10; we run a DB pool of 10 to handle roughly 100k hits per day. We run an almost 100% dynamic site and those 10 connections handle the load admirably. If the number of DB connections grows, we know that either our load has grown all of a sudden or there is a DB issue. 98% of the time, it is a DB issue. We have gotten rid of the socket closure issue as the developers jobs were on the line after they audited the socket closures that caused a few production outages. HTH, Ben Ricker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maxThreads
Yes, on Solaris it's 'kill -3 pid'. The thread dump will go to wherever you have redirected stdout, catalina.out by default I believe. -chris -Original Message- From: Geralyn M Hollerman [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 1:44 PM To: [EMAIL PROTECTED] Subject: Re:maxThreads Halstead, Chris wrote: The first thing you need is a thread dump of the Tomcat process at the time you are experiencing all threads busy. You are 100% correct in your assumption that raising maxThreads will just delay the inevitable. Once you have a thread dump you can investigate what section of code has all of your threads blocked. Until then it's all just speculation... Thank you! I'll try that! I did that once before, when I was testing things...kill -3 PID was it? (I'm on a Solaris box) I *hope* I wrote that down! -- Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maxThreads Settingd
Howdy, Max threads for what? Request processor threads are controllable via minProcessors and maxProcessors in the HTTP/1.1 connector element. Yoav Shapira Millennium ChemInformatics -Original Message- From: Billy Ng [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 9:22 PM To: Tomcat Users List Subject: maxThreads Settingd Hi folks; Would anybody tell me if there is a way to change the maxThreads for Tomcat 4.0? I don't see the option in server.xml Thanks! Billy Ng This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
