Re: svn commit: r572181 - in /tomcat/connectors/trunk/jk/native/common: jk_ajp12_worker.c jk_ajp_common.c jk_jni_worker.c jk_status.c

[Rainer Jung <ra...@kippdata.de>]

Hi Mladen,

I'm fine with rolling back and committing in steps.
Will do later today. Usually I do it like that (see jk_map comits 
yesterday), but it got a little late yesterday :(

This was motivated by BZ43229. We partially lost track of the many 
return codes of the service() methods of all the different workers and 
the helper methods in jk_ajp_common(). We test against unused return 
codes, but forgot others. I hope you'll see, that the changes make 
sense, after breaking them up into parts, which are easier to track.

After adding the code comments about the used return values, I'm 
thinking about the reverse process, i.e.

- discussing after which stages we accept a request as recoverable by 
the local worker or/and by an lb (and then check the code against that 
definition)
- defining under which conditions an lb should put a worker into error
- defining, which meaning our service return codes have
- checking the bundled is_error

Regards,

Rainer

Mladen Turk wrote:
> Huh, this is one huge single commit :(
> I must say it's really hard to follow something like that, and now I
> see that I'll for sure never do again something like that by myself.
> 
> Can we in the future try to make the commits that a single-topic
> related? I know it's additional hassle, but lot less then the one
> when someone really tries to understand the patch.
> 
> 
> Regards,
> Mladen.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: svn commit: r572181 - in /tomcat/connectors/trunk/jk/native/common: jk_ajp12_worker.c jk_ajp_common.c jk_jni_worker.c jk_status.c

[Mladen Turk <mt...@apache.org>]

Rainer Jung wrote:
> Hi Mladen,
> 
> I'm fine with rolling back and committing in steps.

No need to do that. Let's just take more care in the future.
It'll be much easier to follow the commits thought.

Regards,
Mladen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org