Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 49234 invoked from network); 22 Jan 2003 22:02:14 -0000 Received: from exchange.sun.com (192.18.33.10) by 208.185.179.12.available.above.net with SMTP; 22 Jan 2003 22:02:14 -0000 Received: (qmail 14049 invoked by uid 97); 22 Jan 2003 22:03:37 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 13968 invoked by uid 97); 22 Jan 2003 22:03:36 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 13940 invoked by uid 98); 22 Jan 2003 22:03:35 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Injected-Via-Gmane: http://gmane.org/ To: tomcat-dev@jakarta.apache.org From: Costin Manolache Subject: Re: [proposal] add the apr_queue mechanism to apr_socket Date: Wed, 22 Jan 2003 13:52:47 -0800 Lines: 47 Message-ID: References: <002901c2c255$82b11fd0$5c00000a@GISDATA.ZG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@main.gmane.org User-Agent: KNode/0.7.1 Sender: news X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N Mladen Turk wrote: > > One more... > > Here is the scenario: > > If TC instance is too busy or reached the connection limit the next > connection is refused, causing entire worker to switch to the error > state. This isn't very smart (at least for threaded servers). > I propose that we use the apr_queue to solve that. > The socket will be pushed to the queue, when successfully connected, and > pop when finished. > If we reach the connection limit the next one will block until the any > of the active one finishes (releasing space in the queue). > Also, if the connection is refused and we have some sockets in the queue > (meaning the TC is busy responding), we'll block untill the connection > is accomplished or timed-out. Alternative solution: When ( connection_limit - 1 ) is reached, we send back a special response code ( OVERLOADED ). Same could be sent if the worker uptime is higher than a certain limit ( if you implement the other proposal ). The response code will not put the worker in error state, just move it to the end of the queue. If all worker are overloaded, we'll just inform the user. Regardless of the solution you choose - I don't think you should block, or at least you should have an option that will switch to the next worker or return a message. It's far better to get a page displaying a progress bar or telling to try later - instead of the "hunged" feeling. Costin > > If there is a connection error caused by the TC's fault, the returned > error from freed one will cause the entire worker to go to the error > state. > > Thoughts? > > MT. -- To unsubscribe, e-mail: For additional commands, e-mail: