You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2002/10/04 23:12:56 UTC
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_wo rker_ajp13.c
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: costin@apache.org [mailto:costin@apache.org]
>> Enviado el: 4 de octubre de 2002 22:29
>> Para: jakarta-tomcat-connectors-cvs@apache.org
>> 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:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_wo
rker_ajp13.c
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> 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.
+1 on using error packets. And we should be able to include Error
Packets into REQUEST AND REPLIES processing, for example included
when a user hit stop when uploading/downloading datas which are
larger than 8K...
I'll take a look at it, and it should be done in a way which is
compatible with current ajp13. The idea will be to determine if
we're using an ajp13 extension level 1 (no more ajp14), which
support strong authentication and so also error packets in
post side (webserver forwarding requests data to tomcat, and
tomcat replying to webserver).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_wo rker_ajp13.c
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
>> -----Original Message-----
>> From: news [mailto:news@main.gmane.org] On Behalf Of Costin Manolache
>> Sent: Friday, October 04, 2002 11:13 PM
>> To: tomcat-dev@jakarta.apache.org
>> Subject: RE: cvs commit:
>> jakarta-tomcat-connectors/jk/native2/common jk_wo rker_ajp13.c
>>
>>
>> Mladen - time for a jk2.0.2 :-) ?
>>
>
> Why 2.0.2, did I miss the 2.0.1 ?
I tought you already tagged 2.0.1.
Actually, even if you did - the tag can be moved.
> That convince me even more that we need a constant service channel
> between the TC and a connector, to be able to deal with the asnyc events
> on both sides.
> I would like to see something like that in 2.1
I don't think it has to wait 2.1 - just add a component on each
side ( as 'experimental' ). I don't see how this would affect
this particular problem without too much complexity, or how it
would work for apache1.3, but it would be very good for other things.
I also need async events for the configuration side - right
now I use the shmem and the jkstatus ( to get around apache1.3
and single-threaded servers ), if you find a better solution it
would be great.
I mentioned in the comment - I think a good solution for the
errors would be a non-roundtrip error message. If a client
error is detected, apache will send a message ( tcp is duplex ).
Tomcat will check available() before sending - it will not
wait for a message, but check if one happened to be received.
This could also take care of other async events.
BTW, I tried to get a central message dispatcher instead
of explicitely looking for particular messages - this is not
yet done, but should be close. If you reach the same conclusion
as I did ( that single threaded models don't allow an async
TCP channel ), probably we'll use the shmem and possibly a small
deamon shared by all apache instances to communicate async events to
tomcat ( and that should include statistical data for the JMX
proxy, etc )
> As for the release, I was trying to push one even before your ajp
> bugfix, so lets go for it.
>
> Can we make some STATUS file explaining bug fixes since 2.0.0?
Do we have one ? We should.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_wo rker_ajp13.c
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Costin Manolache
> Sent: Friday, October 04, 2002 11:13 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: cvs commit:
> jakarta-tomcat-connectors/jk/native2/common jk_wo rker_ajp13.c
>
>
> Mladen - time for a jk2.0.2 :-) ?
>
Why 2.0.2, did I miss the 2.0.1 ?
> I think this was a serious bug - if Nacho confirms the other
> tests are passing, we need to push it into a milestone.
>
I'll do the tests on my side.
> 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.
>
That convince me even more that we need a constant service channel
between the TC and a connector, to be able to deal with the asnyc events
on both sides.
I would like to see something like that in 2.1
As for the release, I was trying to push one even before your ajp
bugfix, so lets go for it.
Can we make some STATUS file explaining bug fixes since 2.0.0?
MT.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>