Mladen - time for a jk2.0.2 :-) ? I think this was a serious bug - if Nacho confirms the other tests are passing, we need to push it into a milestone.
As a note: breaking the ajp connection on error is IMO the best solution for now. If we start doing strong authentication ( i.e. the ajp extensions that Henri proposed ) - then it may be expensive, and we should explore sending an error packet and ignoring all further incoming messages from tomcat. The java side should also check available() before sending any message. That will still avoid the roundtrips. Costin Ignacio J. Ortega wrote: > Bingo !! for me it's working now.. > > Need to some formal tests but seems to be working nice now.. Thanks > > Saludos , > Ignacio J. Ortega > > >> -----Mensaje original----- >> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >> Enviado el: 4 de octubre de 2002 22:29 >> Para: [EMAIL PROTECTED] >> Asunto: cvs commit: jakarta-tomcat-connectors/jk/native2/common >> jk_worker_ajp13.c >> >> >> 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_worke >> r_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: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> >> -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
