Status 2.2.7?

[Ruediger Pluem <rp...@apache.org>]

As far as I remember there was a desire to release 2.2.7 soon as 2.2.6
introduced some incompatibilities with mod_fastcgi and mod_perl on Windows due
to changes to avoid file descriptor leaks on Windows. Other Bill worked hard
on the needed fixes in APR and so the original plan was to wait on the next APR
1.2.x release containing these fixes before releasing 2.2.7. But it turned
out that Bill's fixes for APR could not be backported to 1.2.x due to APR's
versioning rules. Then Bill proposed a patch for 2.2.x in the STATUS file
which I commented on:

http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix-log.c.patch

Is this patch now essentially the show stopper for 2.2.7 (as we want to fix the
situation on Windows that started with 2.2.6)? Or do we have to wait for the next
1.2.x APR release to solve this issue (or possible other issues)?
I saw that besides many other things Bill worked a lot on the Windows make files
for APR. Are they a wanted prerequisite for 2.2.7?


Regards

Rüdiger

Re: Status 2.2.7?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Ruediger Pluem wrote:
> As far as I remember there was a desire to release 2.2.7 soon as 2.2.6
> introduced some incompatibilities with mod_fastcgi and mod_perl on Windows due
> to changes to avoid file descriptor leaks on Windows. Other Bill worked hard
> on the needed fixes in APR and so the original plan was to wait on the next APR
> 1.2.x release containing these fixes before releasing 2.2.7. But it turned
> out that Bill's fixes for APR could not be backported to 1.2.x due to APR's
> versioning rules. Then Bill proposed a patch for 2.2.x in the STATUS file
> which I commented on:
> 
> http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix-log.c.patch

I have finally dug my head deep enough out of the sand to attend to this patch,
and to the patch I withdrew for mpm_winnt which also corresponds to the reversion,
so I'll validate/champion/explain that in further detail today.

> Is this patch now essentially the show stopper for 2.2.7 (as we want to fix the
> situation on Windows that started with 2.2.6)? Or do we have to wait for the next
> 1.2.x APR release to solve this issue (or possible other issues)?

Yes, it is.  Might also be an issue on other platforms - OS specifically, I still
need to verify.  Remember our history; once upon a time we invoked loggers with
direct exec() invocation, and trusted that they didn't mess with file handles.
Now, we invoke through shell.  Some shells want all three handles and try to
"correct" missing entries with console fd's they cannot obtain in a daemonized
state.  Although the obvious flaw is in win32 cmd.exe, I've had reports of such
essoteric never-used shells such as older solaris /bin/sh throwing up over some
very similar issue (while /usr/xpg4/bin/sh doesn't appear to have issues.)

So we absolutely need this corrected in a portable way, and validated across some
number of platforms.  I have an assistant at work investigating how to incorporate
piped error and access logs (and access covering most addt'l use cases) into the
perl-framework, which I hope can be used to 'bless' the full solution.

> I saw that besides many other things Bill worked a lot on the Windows make files
> for APR. Are they a wanted prerequisite for 2.2.7?

APR 1.2.next is a prerequisite, yes.  Ignore the build fixes which almost entirely
lead to buildable x64 vc solutions and apr[-util] test invocations.  Many other code
fixes in there are very necessary.

But the trouble is, today, OS/X mac users have sendfile detected, no implementation,
and a broken build.  My hack of a possible-darwin sendfile is not passing our own
test/sendfile blocking test (first one to try to prove right), but it's bizzare.
In the blocking test server reports sent 270029 of expected 390049 (with no error
result this would correspond to trailers being ditched).  It appears to be partly
because the client gives up on reading, but we should have seen an rv!...

Server test reports a mismatched byte at 119880 bytes into the sendfile-sent-file.
It bails then, which would explain why the client can't send trailers (but doesn't
explain why they don't tell us that in blocking mode with an rv in addition to the
mismatched size!)

So APR 1.2.now isn't ready considering the bug reports will be flowing in.  I fixed
atomics dylib construction for the most modern compilers on mac, need to backport.
But we still need to either cripple sendfile, or determine why it or my implementation
are misbehaving.

There is one ill each in apr-iconv/apr-util;

   apr-iconv; when completing utf8-utf7 we don't leave the shift state, easy to reproduce
   from the apr-util test framework (on any platform - just --with-iconv=apr-iconv path).

   apr-util; reslist as a test sucks, takes forever on any platform and should be yanked
   from abts_headers.h list and the build.  On 1.2 it's worse, my attempt to backport it
   into non-threadpool'ing 1.2 from trunk was a failure.  Given that trunk is worse, I'm
   about to svn remove the damned thing ;-)

Bill

Re: Status 2.2.7?

[Jim Jagielski <ji...@jaguNET.com>]

On Oct 28, 2007, at 9:09 AM, Ruediger Pluem wrote:

> As far as I remember there was a desire to release 2.2.7 soon as 2.2.6
> introduced some incompatibilities with mod_fastcgi and mod_perl on  
> Windows due
> to changes to avoid file descriptor leaks on Windows. Other Bill  
> worked hard
> on the needed fixes in APR and so the original plan was to wait on  
> the next APR
> 1.2.x release containing these fixes before releasing 2.2.7. But it  
> turned
> out that Bill's fixes for APR could not be backported to 1.2.x due  
> to APR's
> versioning rules. Then Bill proposed a patch for 2.2.x in the  
> STATUS file
> which I commented on:
>
> http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix- 
> log.c.patch
>
> Is this patch now essentially the show stopper for 2.2.7 (as we  
> want to fix the
> situation on Windows that started with 2.2.6)? Or do we have to  
> wait for the next
> 1.2.x APR release to solve this issue (or possible other issues)?
> I saw that besides many other things Bill worked a lot on the  
> Windows make files
> for APR. Are they a wanted prerequisite for 2.2.7?
>

IMO, I do consider this a showstopper and 2.2.7 should wait
until fixed. I plan on doing a 2.2.7 (as well as 1.3.40)
release "real soon" once these issues are resolved...