Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 7591 invoked from network); 4 Oct 2002 20:29:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Oct 2002 20:29:38 -0000 Received: (qmail 9946 invoked by uid 97); 4 Oct 2002 20:30:14 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 9847 invoked by uid 97); 4 Oct 2002 20:30:13 -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 9716 invoked by uid 97); 4 Oct 2002 20:30:12 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: 4 Oct 2002 20:29:19 -0000 Message-ID: <20021004202919.27510.qmail@icarus.apache.org> From: costin@apache.org To: jakarta-tomcat-connectors-cvs@apache.org Subject: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_ajp13.c X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N costin 2002/10/04 13:29:19 Modified: jk/native2/common jk_worker_ajp13.c Log: Tentative fix for 12346. If an unrecoverable error happens ( for example when the client hits stop - the server can't send more data since the connection is lost ) we need to forcefully break the ajp13 connection, since tomcat can't know this and will continue to send data. This behavior is a result of the optimizations made for the 'normal' case, i.e. the fact that tomcat doesn't wait for confirmation when sending chunks of data. Adding the roundtrip will have big negative performance hit - and it's better to deal with the error cases. Note that the alternative ( and what seems to happen for apache ) is to ignore the server errors and continue to receive chunks and ignore them. That can save the ajp connection - with the price of having tomcat send useless data. For a large file that may be a bad solution, and tomcat will not be notified that the client had problems ( which may be a usefull info ). If this doesn't fix the problem - please send me logs with ajp debug enabled. I can't reproduce it ( or run IIS ), but this is clearly a bug.. Revision Changes Path 1.39 +7 -3 jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c Index: jk_worker_ajp13.c =================================================================== RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c,v retrieving revision 1.38 retrieving revision 1.39 diff -u -r1.38 -r1.39 --- jk_worker_ajp13.c 8 Jul 2002 13:34:26 -0000 1.38 +++ jk_worker_ajp13.c 4 Oct 2002 20:29:19 -0000 1.39 @@ -398,6 +398,8 @@ env->l->jkLog(env, env->l, JK_LOG_ERROR, "ajp13.service() ajpGetReply unrecoverable error %d\n", err); + /* The connection is compromised, need to close it ! */ + e->worker->in_error_state = 1; return JK_ERR; } @@ -431,7 +433,8 @@ env->l->jkLog(env, env->l, JK_LOG_DEBUG, "ajp13.forwardST() After %d\n",err); - + /* I assume no unrecoverable error can happen here - we're in a single thread, + so things are simpler ( at least in this area ) */ return err; } @@ -498,7 +501,8 @@ } if (err != JK_OK){ env->l->jkLog(env, env->l, JK_LOG_ERROR, - "ajp13.service() Error forwarding %s\n", e->worker->mbean->name); + "ajp13.service() Error forwarding %s %d %d\n", e->worker->mbean->name, + e->recoverable, e->worker->in_error_state); } if( w->mbean->debug > 0 ) @@ -533,7 +537,7 @@ return JK_ERR; } - if( w->in_error_state ) { + if( w->in_error_state ) { jk2_close_endpoint(env, e); /* if( w->mbean->debug > 0 ) */ env->l->jkLog(env, env->l, JK_LOG_INFO, -- To unsubscribe, e-mail: For additional commands, e-mail: