httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Windows 2.3.13 :: Win32DisableAcceptEx
Date Thu, 29 Sep 2011 19:22:12 GMT
On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
<wrowe@rowe-clan.net> wrote:
> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>> I have an error log full of these;
>>
>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572] (OS 64)The
>> specified network name is no longer available.  : winnt_accept: Asynchronous AcceptEx
failed.
>
> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
> confusing the issue if you build with Win32 IPv6 toggled on, depending on
> your operating system and the SDK you used to build... it was introduced
> in 1.4.3, you might want to try reverting this patch after first working
> through the ticket below...

That doesn't look hopeful, as that patch only modifies behavior for
Windows < Vista; Greg reports the same problem with XP *and Vista*.
(OS level detection would have to be broken?)

>
>> Thanks to Steffen's bringing this up, I now know how I should be fixing this.
>>
>> The problem is, if I set
>>
>> AcceptFilter http none
>>
>> I lose all my vhosts and everything reverts to the main host. If I use
>
> Implies that the host headers are not queried for ***normal*** sockets,
> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
> it looks like this was "optimized" (read:bugged) away.

Supposedly that commit means "hey, we just got the peername from
accept(); don't call getpeername()".

I don't follow the "host headers are not queried" connection to
anything in APR...  (I guess we're talking about name-based vhosts.)


>
> Could you please revert this APR 1.4.3 change and report back what you
> observe?  Another option is to simply try APR 1.4.2 binaries.
>
> It seems AcceptEx() crap still pollutes APR.  We can't optimize for the
> AcceptEx() case because that is handled in httpd.  The flag simply prevents
> us from querying twice (and this becomes stranger because getpeername()
> simply fails for an AcceptEx'ed socket anyways).  The unknown flag can only
> be tripped if we can affirmatively set the correct value.
>
>



-- 
Born in Roswell... married an alien...

Mime
View raw message