DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-06-18 18:35 --- This connector is deprecated and no longer supported. Please use the Coyote HTTP connector instead. No further work will take place against this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|FIXED | Version|4.0.3 Final |4.1.12 --- Additional Comments From [EMAIL PROTECTED] 2004-03-11 17:43 --- I just ran into the same problem with Tomcat 4.1.12! I'm running JMeter to stress an app, and after a couple of hours nothing else can connect and I get hundreds of lines of this error in the logs. We are running 180 threads hitting tomcat, but with random delays on each thread of between 0 and 10 minutes, so I wouldn't call this a very heavy load. Apparently this was fixed for 4.0.4-b1, according to Remy's comments below. Any ideas? Many thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED OS/Version|All |Windows NT/2K Platform|All |PC Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-03-21 08:23 --- I can reproduce this bug every time with the following: Tomcat 4.0.3 JRE 1.4 (final release) Turbine TDK 2.1 - Sample App http://jakarta.apache.org/builds/jakarta-turbine/release/2.1/ Using IE 5.0 goto the URL: http://localhost:8080/newapp/servlet/newapp and hold down the F5 key for a bit. Using JRE 1.3 it does not reproduce. After walking through the code, it appears (to someone not familiar with the source) that this exception prevents the recycle of the HttpProcessor. The net effect is that once maxProcessors is exceeded the server can never accept requests again. Stack Trace: java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END at java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEnc oder.java:933) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529) at sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEncoder.ja va:356) at sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222) at java.io.PrintWriter.close(PrintWriter.java:137) at org.apache.catalina.connector.ResponseBase.finishResponse(ResponseBas e.java:482) at org.apache.catalina.connector.HttpResponseBase.finishResponse(HttpRes ponseBase.java:236) at org.apache.catalina.connector.http.HttpResponseImpl.finishResponse(Ht tpResponseImpl.java:288) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso r.java:1039) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja va:1107) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-03-21 16:13 --- This is a bug with JDK 1.4. The processor not being recycled in that particular case has been fixed in 4.0.4-b1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2002-03-20 09:16 --- Thanx for your 'article' on performance tuning, good information to have. We already tuned our application as you described (not everything ofcourse). In our case I found out that the we started having the HttpConnector problem after some enthusiastic system administrator had turned off some default services which run on Win2K Server. After he put everything back, the problem was solved. Unfortunately, afterwards he could not tell me which services he had stopped (what a system admin huh?). The server load has increased up till 4 times (compared to the load when the problem occurred) without having any problems (FYI we now reach over 120,000 hits per hour at peak values) So I agree with you that Tomcat itself was not the problem. If I'll ever find out what services kept Tomcat from running at full speed, I'll let you know. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
excellent technical analyze. should be present in tomcat faq - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 4:26 AM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2002-03-20 03:26 --- I have not run into this problem using the Tomcat HTTP connector, but I have seen similar problems when using mod_jk to connect to Tomcat via AJP on a server with heavy load. In my case, after alot of detective work, I determined that Tomcat itself was not the problem. There are alot of things which can affect the ability of Tomcat to handle a request regardless of whether they come from its own HTTP connector or from Apache via AJP. You may have already looked at one or more of the following issues, I will include everything just for completeness. The first thing I found is that JVM garbage collection can have a significant intermittent effect on Tomcat. When GC occurs processing by Tomcat freezes, yet the OS will continue to accept requests on the port. When GC has completed, Tomcat will try to handle all pending requests. If the GC took a significant amount of time, this can cause a cascading affect where Tomcat runs out of processors to handle requests. I made the mistake of setting the JVM -Xmx too large. The JVM ended up using more memory than the OS would keep in physical memory, when a Full GC occurred, performing GC on objects swapped out to disk caused GC to take a significant amount of time. In my case, 70 seconds. Decreasing the -Xmx to make sure the JVM stack was always resident in physical memory fixed the problem. JVM Memory Usage and Garbage Collection --- It is very important to tune the JVM startup options for GC and JVM memory usage for a production server. 1. Make sure you are running Tomcat with a JVM that supports Hotspot -server, I use 1.3.1_02. 2. Use incremental GC, the -xincgc java startup option. 3. Try running Tomcat with the -verbose:gc java arg so you can collect data on GC. 4. Make sure the OS is keeping all JVM stack in physical memory and not swapping it out to disk. Reduce -Xmx if this is a problem. 5. Try setting -Xms and -Xmx to the same size. 6. Search the fine web for articles on JVM GC and JVM performance tuning. After researching and testing all of the above I significantly reduced the maximum time for GC's. 99% of my GC's now run in .05 sec, of the remaining, most run at 1 sec, no more than 5-10 times a day do I see a GC 1 sec, and they never exceed 5 sec. dB access by applications - If your applications uses a db, make sure you set it's connection timeout to a value the max GC time you see. Otherwise you will start seeing db connection failures. I set my db connection timeouts to 10 seconds. A problem with your database, or if you frequently reach the maxiumum connections you allow in a db connection pool can cause the type of problems you see. If the db connections fail, or your connection pool is exhaused, each servlet which is waiting for a connection (remember I recommended 10 seconds) will eat up an HTTP or AJP processor for 10 seconds. This can cause a cascading effect where you see alot of processors used by Tomcat. Check your web applications for thread locking problems, or long delays. --- Tomcat can't do anything useful by itself, its the applications you install that provide the content. There could very well be thread locking problems or other bugs which cause delays in a servlet handling a request. This can cause Tomcat to appear to fail due to runaway use of Processors. Increase maxProcessors -- Increase your maxProcessors to handle intermittent cascading of requests due to GC, etc. I set my maxProcessors to 2X max concurrent requests I see under heavy load. Proposition for a change to Processors to help debug these problems Adding code to Processors so that they dump a stack trace for each existing thread when the pool of processors is exhausted could provide valuable information
Re: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
excellent technical analyze. should be present in tomcat faq Yes. AFAIK, there's no FAQ, though :-( Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
How about create a new doc titled Tunning/Troubleshooting and add to Tomcat doc? Punky - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, March 21, 2002 4:14 AM Subject: RE: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection excellent technical analyze. should be present in tomcat faq - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 4:26 AM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2002-03-20 03:26 --- I have not run into this problem using the Tomcat HTTP connector, but I have seen similar problems when using mod_jk to connect to Tomcat via AJP on a server with heavy load. In my case, after alot of detective work, I determined that Tomcat itself was not the problem. There are alot of things which can affect the ability of Tomcat to handle a request regardless of whether they come from its own HTTP connector or from Apache via AJP. You may have already looked at one or more of the following issues, I will include everything just for completeness. The first thing I found is that JVM garbage collection can have a significant intermittent effect on Tomcat. When GC occurs processing by Tomcat freezes, yet the OS will continue to accept requests on the port. When GC has completed, Tomcat will try to handle all pending requests. If the GC took a significant amount of time, this can cause a cascading affect where Tomcat runs out of processors to handle requests. I made the mistake of setting the JVM -Xmx too large. The JVM ended up using more memory than the OS would keep in physical memory, when a Full GC occurred, performing GC on objects swapped out to disk caused GC to take a significant amount of time. In my case, 70 seconds. Decreasing the -Xmx to make sure the JVM stack was always resident in physical memory fixed the problem. JVM Memory Usage and Garbage Collection --- It is very important to tune the JVM startup options for GC and JVM memory usage for a production server. 1. Make sure you are running Tomcat with a JVM that supports Hotspot -server, I use 1.3.1_02. 2. Use incremental GC, the -xincgc java startup option. 3. Try running Tomcat with the -verbose:gc java arg so you can collect data on GC. 4. Make sure the OS is keeping all JVM stack in physical memory and not swapping it out to disk. Reduce -Xmx if this is a problem. 5. Try setting -Xms and -Xmx to the same size. 6. Search the fine web for articles on JVM GC and JVM performance tuning. After researching and testing all of the above I significantly reduced the maximum time for GC's. 99% of my GC's now run in .05 sec, of the remaining, most run at 1 sec, no more than 5-10 times a day do I see a GC 1 sec, and they never exceed 5 sec. dB access by applications - If your applications uses a db, make sure you set it's connection timeout to a value the max GC time you see. Otherwise you will start seeing db connection failures. I set my db connection timeouts to 10 seconds. A problem with your database, or if you frequently reach the maxiumum connections you allow in a db connection pool can cause the type of problems you see. If the db connections fail, or your connection pool is exhaused, each servlet which is waiting for a connection (remember I recommended 10 seconds) will eat up an HTTP or AJP processor for 10 seconds. This can cause a cascading effect where you see alot of processors used by Tomcat. Check your web applications for thread locking problems, or long delays. --- Tomcat can't do anything useful by itself, its the applications you install that provide the content. There could very well be thread locking problems or other bugs which cause delays in a servlet handling a request. This can cause Tomcat to appear to fail due to runaway use of Processors. Increase maxProcessors -- Increase your maxProcessors to handle intermittent cascading of requests due to GC, etc. I set my maxProcessors to 2X max concurrent requests I see under heavy load. Proposition
RE: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
good idea, and adding the technical analisys of glenn is mandatory ;) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Punky Tse [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 3:57 AM To: Tomcat Developers List Subject: Re: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection How about create a new doc titled Tunning/Troubleshooting and add to Tomcat doc? Punky - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, March 21, 2002 4:14 AM Subject: RE: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection excellent technical analyze. should be present in tomcat faq - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 4:26 AM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2002-03-20 03:26 --- I have not run into this problem using the Tomcat HTTP connector, but I have seen similar problems when using mod_jk to connect to Tomcat via AJP on a server with heavy load. In my case, after alot of detective work, I determined that Tomcat itself was not the problem. There are alot of things which can affect the ability of Tomcat to handle a request regardless of whether they come from its own HTTP connector or from Apache via AJP. You may have already looked at one or more of the following issues, I will include everything just for completeness. The first thing I found is that JVM garbage collection can have a significant intermittent effect on Tomcat. When GC occurs processing by Tomcat freezes, yet the OS will continue to accept requests on the port. When GC has completed, Tomcat will try to handle all pending requests. If the GC took a significant amount of time, this can cause a cascading affect where Tomcat runs out of processors to handle requests. I made the mistake of setting the JVM -Xmx too large. The JVM ended up using more memory than the OS would keep in physical memory, when a Full GC occurred, performing GC on objects swapped out to disk caused GC to take a significant amount of time. In my case, 70 seconds. Decreasing the -Xmx to make sure the JVM stack was always resident in physical memory fixed the problem. JVM Memory Usage and Garbage Collection --- It is very important to tune the JVM startup options for GC and JVM memory usage for a production server. 1. Make sure you are running Tomcat with a JVM that supports Hotspot -server, I use 1.3.1_02. 2. Use incremental GC, the -xincgc java startup option. 3. Try running Tomcat with the -verbose:gc java arg so you can collect data on GC. 4. Make sure the OS is keeping all JVM stack in physical memory and not swapping it out to disk. Reduce -Xmx if this is a problem. 5. Try setting -Xms and -Xmx to the same size. 6. Search the fine web for articles on JVM GC and JVM performance tuning. After researching and testing all of the above I significantly reduced the maximum time for GC's. 99% of my GC's now run in .05 sec, of the remaining, most run at 1 sec, no more than 5-10 times a day do I see a GC 1 sec, and they never exceed 5 sec. dB access by applications - If your applications uses a db, make sure you set it's connection timeout to a value the max GC time you see. Otherwise you will start seeing db connection failures. I set my db connection timeouts to 10 seconds. A problem with your database, or if you frequently reach the maxiumum connections you allow in a db connection pool can cause the type of problems you see. If the db connections fail, or your connection pool is exhaused, each servlet which is waiting for a connection (remember I recommended 10 seconds) will eat up an HTTP or AJP processor for 10 seconds. This can cause a cascading effect where you see alot of processors used by Tomcat. Check your web applications for thread locking problems, or long delays
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Critical Status|REOPENED|RESOLVED Component|Catalina|HTTP/1.1 Connector Priority|Other |High Resolution||WORKSFORME Version|4.0 Beta 1 |4.0.3 Final --- Additional Comments From [EMAIL PROTECTED] 2002-03-15 20:39 --- I still lack a test case, or some conclusive information on this bug. Also, I don't think adding a retry mechanism is necessary. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-03-06 13:39 --- Urgent!: We are experiencing the same error: HttpConnector [8080] No processor available, rejecting this connection. It seems that this error occurs under heavy load, resulting in gaps in web pages serverd by tomcat (missing images), server returned an unrecognized response, blank pages, no repsonse at all. Very unpredictable behaviour! Log file shows up till 20 lines whith same error message. When the load decreases the error disappears. We are running Apache Tomcat/4.0-b6-dev on Win2000 Server / SDK 1.3.1 Phenomena can be viewed at http://www.stemwijzer.nl (a dutch site, about elections). Try refreshing the page several times to show the problem. We'll try the solution provided by Dirk Herrmann. Please respond. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2002-03-06 17:29 --- First of all, you should upgrade, because 4.0b6 may be vulnerable to URL-based security hacks. I understand it can be very hard to upgrade a production server, but you should plan to do it here. I never experienced that particular problem, so I'm afraid I can't help much. There are no known problems with the thread pooling code. I tried accessing your site, and didn't run into any problems. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Normal OS/Version|Solaris |All Platform|Sun |All --- Additional Comments From [EMAIL PROTECTED] 2002-01-17 22:18 --- under heavy load (more then 200 request at same time) this coud be help, changes marked as !!! Changed !!! /* * $Header: /home/a430499/PROJECTS/C-JAVIS/repository/de/bbdata/javis30/fix/HttpConnector.java,v 1.1 2002/01/18 05:35:31 a430499 Exp $ * $Revision: 1.1 $ * $Date: 2002/01/18 05:35:31 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * * [Additional notices, if required by prior licensing conditions] * */ package org.apache.catalina.connector.http; import java.io.IOException; import java.net.InetAddress; import java.net.ServerSocket; import java.net.Socket; import java.security.AccessControlException; import java.util.Stack; import java.util.Vector; import java.util.Enumeration; import org.apache.catalina.Connector; import org.apache.catalina.Container; import org.apache.catalina.HttpRequest; import org.apache.catalina.HttpResponse; import org.apache.catalina.Lifecycle; import org.apache.catalina.LifecycleEvent; import org.apache.catalina.LifecycleException; import org.apache.catalina.LifecycleListener; import org.apache.catalina.Logger; import org.apache.catalina.Request; import org.apache.catalina.Response; import org.apache.catalina.Service; import org.apache.catalina.net.DefaultServerSocketFactory; import org.apache.catalina.net.ServerSocketFactory; import org.apache.catalina.util.LifecycleSupport; import org.apache.catalina.util.StringManager; /** * Implementation of an HTTP/1.1 connector. * * @author Craig R. McClanahan * @author Remy Maucherat * @version $Revision: 1.1 $ $Date: 2002/01/18
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2001-12-05 16:32 --- I have tested this extensively using ab (which is the load testing tool from Apache), without experiencing any problems. Since no further details were given, except than the bug was obvious (which clearly isn't the case for me), I'll close the bug. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection [EMAIL PROTECTED] changed: What|Removed |Added Summary||HttpConnector [8080] No ||processor available, ||rejecting this connection -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2001-11-30 11:23 --- You can change the max and min processors till the cow come home it ignore these. Why don't you guys get a loadrunner and try it yourselves. You should see the problem right aways -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2001-11-30 11:40 --- FYI this is on Linux Redhat 7.0 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5181] - HttpConnector [8080] No processor available, rejecting this connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5181 HttpConnector [8080] No processor available, rejecting this connection --- Additional Comments From [EMAIL PROTECTED] 2001-11-29 07:44 --- Could you: - Upgrade to 4.0.1 - Give more details about your configuration and the web traffic, since this is the first report about that we got You can also try to raise the number of processors (using the 'maxProcessors' attribute of the Connector). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
