State of the beta

[Cliff Woolley <cl...@yahoo.com>]

Okay guys, here's the status.  In about three hours, I have to head toward
BWI to catch a plane to Austin, TX.  I'll be there attending NVIDIA-U for
the next 48 hours.  [For those who didn't know, my research interest
focuses on 3D graphics.]  I'm taking my notebook with me, but I don't know
how good my connectivity will be, if I even manage to get online at all.

Anyhow, that means I'm essentially going to have to put a 48-hour hold on
the release of 2.0.22-beta.  (Frankly, I never expected you guys to +1 it
as fast as you did.  =-)  That's just as well, seeing as my message to
current-testers has not even gone out yet.  (Can whoever is the moderator
of that list please see to it that my message gets approved ASAP?
Thanks.)  I'd like to give the current-testers that 48 hours to bang on
the tarball in case there's something very important that we've missed.
I doubt there is anything--we've heard from just about all corners of the
world OS-wise and seem to be doing pretty well on everything except
Darwin.  But if we're gonna do it we might as well get it right.

There are currently two problems with 2.0.22 that I kind of wish were
fixed but aren't: (1) there are build problems that could be easily fixed
to make Mac OS X/Darwin users' lives easier, (2) there are threaded MPM
problems still remaining, which we knew, though it now appears that the
worst of them could be easily fixed.  Is the gethostbyname_r problem that
just got fixed in APR going to cause us headaches on the beta?  If so,
make that (3).  There are other issues that have already been fixed in CVS
since 2.0.22 as well, like exec cgi on Win32, though the ones above are
probably the highest up on the importance scale.

So here's what I propose:  When I return in the wee hours of the morning
on Thursday, I'll get to work and catch up on my email if in fact I'm cut
off from the world for the next two days.  If we haven't heard anything
bad from the current-testers and nobody on this list speaks up to the
contrary between now and then, I'll release 2.0.22 as beta first thing
Thursday morning.  On the other hand, if we do hear about other problems
from the current-testers or fixes for any of the above mentioned problems
get committed and tested between now and Thursday [hint, hint], then I'll
scratch 2.0.22 and roll 2.0.23 and we'll try to expedite getting 2.0.23
out the door ASAP.

Does that sound like a plan?

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA

Re: State of the beta

[Greg Ames <gr...@remulak.net>]

Justin Erenkrantz wrote:

> 2) Maybe, maybe not.  I really like the worker MPM.  I don't see the
> threaded MPM working 

Can you actually make threaded stop serving requests in some situation
(including restarts), with the current code?  Have you actually tried
it?  If not, perhaps you should qualify what you mean by not working. 
Otherwise you are unnecessarily frightening away potential users of our
2.0.22 tarball.  

I believe the main externally visible issue with threaded is that
shutdowns take longer than they could, if incoming connections dry up. 
Yeah, that's not good for a tiny site, but not a big deal for a site
with a fair amount of traffic.   The tiny site folks can just use
prefork for now.

I just fixed a couple of problems that will cause 2.0 servers to stall. 
They had absolutely nothing to do with locks, everything to do with
managing the number of active processes and threads.  Please observe
that the fixes went into both worker and threaded. 

>                unless it looks a lot like worker MPM (but even
> more confusing due to the extra locks).  However, it is going to take
> a few days (a week?) to get worker MPM solid.  Then, we can evaluate
> how it compares to threaded.  rbb and I think we can get the shutdown
> and restart mechanisms working with this model.  I'm not sold on
> the current threaded MPM working.

As I said before, I'll be happy for worker becoming the primary
multithreaded Unix MPM, once it becomes stable, for a number of reasons. 

In the mean time, I'm not aware of anyone who can make threaded stop
serving requests when it should be.  I can't break it.  Austin had it up
& running with PHP4.  Cliff was able to break some level of threaded by
doing several graceful restarts per second.  Even that is fixed in cvs
now, AFAIK.

Greg

Re: State of the beta

[Sander Temme <sc...@covalent.net>]

on 7/30/01 10:57 PM, Justin Erenkrantz at jerenkrantz@ebuilt.com wrote:

> 1) I don't have a Darwin box.  If someone wants to donate one to me, I'd
> like one.  =-)

I understand Apple has a box outside the firewall that they can give you an
account on. I think it's sandbox.opensource.apple.com but am not sure. Fred?

S.

-- 
Covalent Technologies                             sctemme@covalent.net
Engineering group                                Voice: (415) 536 5214
645 Howard St.                                     Fax: (415) 536 5210
San Francisco CA 94105

   PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03  5531 AFB1 96AF B584 0AB1

=======================================================
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
=======================================================

Re: State of the beta

[Justin Erenkrantz <je...@ebuilt.com>]

On Mon, Jul 30, 2001 at 10:37:08PM -0400, Cliff Woolley wrote:
> 
> Okay guys, here's the status.  In about three hours, I have to head toward
> BWI to catch a plane to Austin, TX.  I'll be there attending NVIDIA-U for
> the next 48 hours.  [For those who didn't know, my research interest
> focuses on 3D graphics.]  I'm taking my notebook with me, but I don't know
> how good my connectivity will be, if I even manage to get online at all.

Get some free video cards for all of us while you are out there.

> There are currently two problems with 2.0.22 that I kind of wish were
> fixed but aren't: (1) there are build problems that could be easily fixed
> to make Mac OS X/Darwin users' lives easier, (2) there are threaded MPM
> problems still remaining, which we knew, though it now appears that the
> worst of them could be easily fixed.  Is the gethostbyname_r problem that
> just got fixed in APR going to cause us headaches on the beta?  If so,
> make that (3).  There are other issues that have already been fixed in CVS
> since 2.0.22 as well, like exec cgi on Win32, though the ones above are
> probably the highest up on the importance scale.

1) I don't have a Darwin box.  If someone wants to donate one to me, I'd
like one.  =-)

2) Maybe, maybe not.  I really like the worker MPM.  I don't see the
threaded MPM working unless it looks a lot like worker MPM (but even
more confusing due to the extra locks).  However, it is going to take 
a few days (a week?) to get worker MPM solid.  Then, we can evaluate 
how it compares to threaded.  rbb and I think we can get the shutdown
and restart mechanisms working with this model.  I'm not sold on
the current threaded MPM working.

3) No, I don't think not having today's gethostbyname_r commit will 
hurt much.  The real problem with gethostbyname_r was pre-Solaris 8
(which was fixed a week or two ago).  Recent Linux distros (dunno 
about AIX) have getaddrinfo(), so they should already be thread-safe.  
If you have an older Linux distro (I'd guess glibc2.0-based without 
IPv6) and you are using threads, you probably want this update.
Show-stopper?  No.  Nice-to-have?  Probably.

I'm going to commit a quick fix that will enable getnameinfo() on 
platforms that have that function but aren't IPv6-enabled (Solaris
7).  -- justin