Re: Windows 2.3.13 :: Win32DisableAcceptEx
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. Greg... were you using AcceptFilter 'connect' or AcceptFilter 'data' in this particular case? The bugs I resolved in the AcceptFilter 'none' case shouldn't touch this. What is your Listen directive? Did you build with APR_HAS_IPV6 == 1? What drivers are on your network stack? Are you running a network layer antivirus sniffer? This exception doesn't appear to be related to socket reuse, which is why I'm especially interested in your config and anything unusual about your environment.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Bill, I was using nothing, so by docs, the default is/was data. XP SP3, IPv6 Proto loaded Yes, APR_HAVE_IPV6 ==1 NVIDIA nForce 10/100/1000 v. 67.8.9.0 8/1/2008 This box originally came with Symantic, and I would assume it was able to sniff, but that was removed and it is just MSSE now, however, Symantic may not be completely gone, or anything replaced reverted. In 2.2, said error signified the need for Win32DisableAcceptEx, which when used, I would never see it again. I would like to start with a clean and not preloaded system on the box, but at this time, that is not possible. Cheers, Gregg On 10/11/2011 3:53 AM, William A. Rowe Jr. 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. Greg... were you using AcceptFilter 'connect' or AcceptFilter 'data' in this particular case? The bugs I resolved in the AcceptFilter 'none' case shouldn't touch this. What is your Listen directive? Did you build with APR_HAS_IPV6 == 1? What drivers are on your network stack? Are you running a network layer antivirus sniffer? This exception doesn't appear to be related to socket reuse, which is why I'm especially interested in your config and anything unusual about your environment.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 9/29/2011 7:30 PM, Jeff Trawick wrote: This is well past the point where one needs to know the Listen configuration, exact problem symptom, etc. ;) Either way it seems that there were some oddities around the presence/absence of IPV6_V6ONLY. In its absence APR should have been returning APR_ENOTIMPL instead of not-set for a query, then httpd would have grown different logic. Right. I discovered that loading an IPv6 APR against a IPv4 compiled libhttpd.dll on Win32 is a very lethal combination. The buffer sizes, for one, are all wrong. Chalk these complaints about APR 1.x up to user-error.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 9/29/2011 2:41 PM, Eric Covener wrote: I took a look at this in the AM, and it looks like the acceptfilter none path is relying on data set only by AcceptEX (context-buffer) to fill in context-sa_server (child.c:590). In 2.2 the context-buffer is seeded by the 9x specific code. Seems like that block of code just needs a backport from win9x_get_connection to set the server side of this structure correctly before it's copied into sockinfo later in the same function. Precisely. As we have context-buff allocated for all AcceptFilter schemes, I added the appropriate queries into that buffer in r1181140, and the world seems at peace again for just this short moment.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Precisely. As we have context-buff allocated for all AcceptFilter schemes, I added the appropriate queries into that buffer in r1181140, and the world seems at peace again for just this short moment. Trying to fully resolve the 2.3 accptex thread -- Should I add a note about Win32DisableAcceptEx to mpm_winnt doc? Or even add it back in as a directive to point to AcceptFilter?
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Note: With 2.2.x not a single issue reported here with Win32DisableAcceptEx, with ipv6 and/or ip4. Idea to revert 2.3 back to the old behaviour ? On Monday 10/10/2011 at 21:23, Eric Covener wrote: Precisely. As we have context-buff allocated for all AcceptFilter schemes, I added the appropriate queries into that buffer in r1181140, and the world seems at peace again for just this short moment. Trying to fully resolve the 2.3 accptex thread -- Should I add a note about Win32DisableAcceptEx to mpm_winnt doc? Or even add it back in as a directive to point to AcceptFilter?
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 10/10/2011 2:34 PM, Steffen wrote: Note: With 2.2.x not a single issue reported here with Win32DisableAcceptEx, with ipv6 and/or ip4. Idea to revert 2.3 back to the old behaviour ? Nope, absolutely not. The old behavior had way too much distinct code between the 9x and nt code paths. As 9x is dead, there is no reason to keep maintaining so much dissimilar code, including two entirely different worker job queue implementations. The new code is drastically simpler, Eric identified (correctly) the missing code, so we should be in good shape now... but follow my other post on bad network stack drivers.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 10/10/2011 2:22 PM, Eric Covener wrote: Precisely. As we have context-buff allocated for all AcceptFilter schemes, I added the appropriate queries into that buffer in r1181140, and the world seems at peace again for just this short moment. Trying to fully resolve the 2.3 accptex thread -- Should I add a note about Win32DisableAcceptEx to mpm_winnt doc? Or even add it back in as a directive to point to AcceptFilter? I'm actually giving this further thought... we have three basic modes right now; acceptex+recycle, acceptex+recycle+data, or accept. Only the acceptex+recycle+data is new. In fact, 90% of users observed acceptex problems were -never- with the acceptex itself. The error occurs in recycling a broken socket handle. Eliminate socket recycling by default and most problems are going to go away, whether it is because a network stack component refuses to properly disconnect a socket and make it ready for recycling, or whether a previously IPv4 socket turns out to be incapable of handling an IPv6 connection on the next go-around. So really, we aught to support acceptex and acceptex+data modes without socket recycling, as well. My preference would be to treat acceptex as 'none'/default. 'data' means acceptex+data. 'accept' means accept, rather than acceptex (and it has no concept of recycling). Then, add 'recycle', or 'recycle+data', for those who wish to use the socket recycling feature. I'd advise against it given everything we've seen over the past 10 years. But if it works as advertised on a user's particular combination of network stack drivers, then let them keep the feature if they explicitly enable it. In fact, since Server 2003 (now that we've killed Server 2000 support)... if (!DisconnectEx(hSock, NULL, TF_REUSE_SOCKET, 0) hSock = INVALID_HANDLE; would let us recycle the non-TransmitFile sockets as well. On a similar note; non-server flavors of Windows have crippled the entire TransmitFile API (SendFile enabled) allowing only two simultaneous file transmissions. I'm thinking of setting SendFile to disabled by default on any non-server Windows OS in the pre-config phase, and letting the user enable it explicitly if desired. I don't see a reason to change the default for windows server OS's.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On Monday 10 October 2011, William A. Rowe Jr. wrote: On 10/10/2011 2:22 PM, Eric Covener wrote: Trying to fully resolve the 2.3 accptex thread -- Should I add a note about Win32DisableAcceptEx to mpm_winnt doc? Or even add it back in as a directive to point to AcceptFilter? Add at least a note to docs/manual/upgrading.xml. On a similar note; non-server flavors of Windows have crippled the entire TransmitFile API (SendFile enabled) allowing only two simultaneous file transmissions. I'm thinking of setting SendFile to disabled by default on any non-server Windows OS in the pre-config phase, and letting the user enable it explicitly if desired. I don't see a reason to change the default for windows server OS's. SendFile is disabled by default since 2.3.9. So nothing needs to be changed there. But if it doesn't work with certain Windows flavors, there should be a note in the SendFile docs.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 9/29/2011 7:30 PM, Jeff Trawick wrote: This is well past the point where one needs to know the Listen configuration, exact problem symptom, etc. ;) Either way it seems that there were some oddities around the presence/absence of IPV6_V6ONLY. In its absence APR should have been returning APR_ENOTIMPL instead of not-set for a query, then httpd would have grown different logic. Agreed, my original assessment was wrong. httpd 2.2 was in a working state with IPv6 on Win2k3/XP but its clearly broken on Win2k8/7 right now. Again, I'm digging through this, but agree with the original assessment that some legacy 9x code needs to be un-removed to get the AcceptFilter 'none' working... and something relative to the new code causes IPv6 to still misbehave on W2k8/7. I'll quit speculating till this is working on both W2K3 and W2K8 for 2.2 (which should be very close to correct already) and then apply that to trunk along with the extra effort to restore the broken accept() code path.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
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=revisionrevision=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... 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=revisionrevision=1088569 it looks like this was optimized (read:bugged) away. 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.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr. wr...@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=revisionrevision=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=revisionrevision=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...
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr. wr...@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=revisionrevision=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... 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=revisionrevision=1088569 it looks like this was optimized (read:bugged) away. 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. I took a windows laymen look in the other 2.4 GA thread, pasted below: I took a look at this in the AM, and it looks like the acceptfilter none path is relying on data set only by AcceptEX (context-buffer) to fill in context-sa_server (child.c:590). In 2.2 the context-buffer is seeded by the 9x specific code. Seems like that block of code just needs a backport from win9x_get_connection to set the server side of this structure correctly before it's copied into sockinfo later in the same function. I can't easily build it and not sure what other non-acceptex 9x-isms are in win9x_get_connection. This matches the reports of the base VH being picked every time, but I couldn't find on the list where the culprit had been identified before.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 9/29/2011 2:22 PM, Jeff Trawick wrote: On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr. wr...@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=revisionrevision=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?) It certainly contributes, maybe something similar is missing from httpd-2.2/2.3-beta sources. The old code certainly appeared to work. 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=revisionrevision=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.) Sorry, bad wording. You can't getpeername() on an AcceptEx() socket. You must getpeername() on non-AcceptEx() sockets. These patch, I believe, broke both 2.3-beta as well as 2.2 when compiled using IPV6 and older VC6/SDK's... my team was able to reproduce problems on Vista/W2K8 that don't exist on W2K3 once your changes are introduced to 2.2 compiled with APR_HAS_IPV6. Also, the apparent splitting of IPV6_ONLY sockets from IPV4/6 sockets causes IPV4 sockets to barf on recycling. Still trying to pin this down. Working on mitigating the damage to 2.2 and 2.3-beta now.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On Thu, Sep 29, 2011 at 5:00 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
On 9/29/2011 2:22 PM, Jeff Trawick wrote:
On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
wr...@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=revisionrevision=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?)
It certainly contributes, maybe something similar is missing from
httpd-2.2/2.3-beta sources. The old code certainly appeared to work.
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=revisionrevision=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.)
Sorry, bad wording. You can't getpeername() on an AcceptEx() socket.
You must getpeername() on non-AcceptEx() sockets.
This patch affects only the accept() (apr_socket_accept()) path. The
WinNT MPM in trunk doesn't call apr_socket_accept().
APR_DECLARE(apr_status_t) apr_socket_accept(apr_socket_t **new,
apr_socket_t *sock, apr_pool_t *p)
{
...
s = accept(sock-socketdes, (struct sockaddr *)sa, salen);
(11 lines omitted)
- (*new)-remote_addr_unknown = 0; -
Obviously this doesn't affect httpd trunk. For 2.2, is the
configuration with Win32DisableAcceptEx broken? (I don't see an
indication of that in this thread.
These patch, I believe, broke both 2.3-beta as well as 2.2 when compiled
using IPV6 and older VC6/SDK's... my team was able to reproduce problems
on Vista/W2K8 that don't exist on W2K3 once your changes are introduced
to 2.2 compiled with APR_HAS_IPV6.
Are any of these problems with 2.2 and Win32DisableAcceptEx enabled?
Let's see...
Windows = Vista, old SDK:
Before the patch: APR_IPV6_V6ONLY returns APR_ENOTIMPL
After the patch: It actually calls setsockopt(); I'm suspicious that
apr_socket_opt_get() never calls getsockopt() but I haven't checked
that thoroughly
From an httpd perspective:
AP_ENABLE_V4_MAPPED is never defined for Windows.
make_sock() thus calls apr_socket_opt_set(s, APR_IPV6_V6ONLY, 1).
Before the patch (old SDK) this was APR_ENOTIMPL, after the patch it
actually calls setsockopt()
open_listeners() calls apr_socket_opt_get(s, APR_IPV6_V6ONLY, ?)
Before the patch (old SDK) this always returned 0; after the patch it
should return 1 (since the apr_socket_opt_set(APR_IPV6_V6ONLY = 1)
worked). IOW, before the patch an IPv6 socket was removed from the
list because it was believed to overlap, now it is not removed from
the list.
Also, the apparent splitting of IPV6_ONLY sockets from IPV4/6 sockets
causes IPV4 sockets to barf on recycling. Still trying to pin this down.
Working on mitigating the damage to 2.2 and 2.3-beta now.
--
Born in Roswell... married an alien...
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On Thu, Sep 29, 2011 at 8:02 PM, Jeff Trawick traw...@gmail.com wrote:
On Thu, Sep 29, 2011 at 5:00 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
On 9/29/2011 2:22 PM, Jeff Trawick wrote:
On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
wr...@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=revisionrevision=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?)
It certainly contributes, maybe something similar is missing from
httpd-2.2/2.3-beta sources. The old code certainly appeared to work.
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=revisionrevision=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.)
Sorry, bad wording. You can't getpeername() on an AcceptEx() socket.
You must getpeername() on non-AcceptEx() sockets.
This patch affects only the accept() (apr_socket_accept()) path. The
WinNT MPM in trunk doesn't call apr_socket_accept().
APR_DECLARE(apr_status_t) apr_socket_accept(apr_socket_t **new,
apr_socket_t *sock, apr_pool_t *p)
{
...
s = accept(sock-socketdes, (struct sockaddr *)sa, salen);
(11 lines omitted)
- (*new)-remote_addr_unknown = 0; -
Obviously this doesn't affect httpd trunk. For 2.2, is the
configuration with Win32DisableAcceptEx broken? (I don't see an
indication of that in this thread.
These patch, I believe, broke both 2.3-beta as well as 2.2 when compiled
using IPV6 and older VC6/SDK's... my team was able to reproduce problems
on Vista/W2K8 that don't exist on W2K3 once your changes are introduced
to 2.2 compiled with APR_HAS_IPV6.
Are any of these problems with 2.2 and Win32DisableAcceptEx enabled?
Let's see...
Windows = Vista, old SDK:
Before the patch: APR_IPV6_V6ONLY returns APR_ENOTIMPL
After the patch: It actually calls setsockopt(); I'm suspicious that
apr_socket_opt_get() never calls getsockopt() but I haven't checked
that thoroughly
From an httpd perspective:
AP_ENABLE_V4_MAPPED is never defined for Windows.
make_sock() thus calls apr_socket_opt_set(s, APR_IPV6_V6ONLY, 1).
Before the patch (old SDK) this was APR_ENOTIMPL, after the patch it
actually calls setsockopt()
open_listeners() calls apr_socket_opt_get(s, APR_IPV6_V6ONLY, ?)
Before the patch (old SDK) this always returned 0; after the patch it
should return 1 (since the apr_socket_opt_set(APR_IPV6_V6ONLY = 1)
worked). IOW, before the patch an IPv6 socket was removed from the
list because it was believed to overlap, now it is not removed from
the list.
This is well past the point where one needs to know the Listen
configuration, exact problem symptom, etc. ;) Either way it seems
that there were some oddities around the presence/absence of
IPV6_V6ONLY. In its absence APR should have been returning
APR_ENOTIMPL instead of not-set for a query, then httpd would have
grown different logic.
Also, the apparent splitting of IPV6_ONLY sockets from IPV4/6 sockets
causes IPV4 sockets to barf on recycling. Still trying to pin this down.
Working on mitigating the damage to 2.2 and 2.3-beta now.
--
Born in Roswell... married an alien...
--
Born in Roswell... married an alien...
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Bill, I think it's been realized that the APR/IPv6 has no bearing on this but I can confirm that 2.3.15-dev at r1177210 with apr 1.4.2 and ipv6 set to 0 does the exact same thing. Cheers, Gregg On 9/29/2011 11:58 AM, William A. Rowe Jr. 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=revisionrevision=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... 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=revisionrevision=1088569 it looks like this was optimized (read:bugged) away. 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.
Re: Windows 2.3.13 :: Win32DisableAcceptEx
Hi, 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. 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 AcceptFilter https none I have no ssl because of the same reason, it reverts to the main host which is not https and I get this in Firefox An error occurred during a connection to servertwo.tld. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) http://servertwo.tld:443 works, but isn't https, and doesn't serve the right document, it serves the document of the main host. Win32DisableAcceptEx never suffered this horrendous problem. What I am seeing in the error log is bizarre; [Thu Jul 07 01:25:28.419000 2011] [core:error] [pid 3332:tid 1532] [client 127.0.0.1:52880] request failed: invalid characters in URI What's invalid about https://servertwo.tld Vista or XP, same thing. Gregg On 7/4/2011 8:52 PM, William A. Rowe Jr. wrote: On 7/4/2011 9:46 AM, Steffen wrote: The widely used Win32DisableAcceptEx is not anymore in 2.3. Can someone confirm that this has the same effect: AcceptFilter http none AcceptFilter https none Maybe an idea to update the upgrading docu on this subject ? http://httpd.apache.org/docs/2.3/mod/core.html#acceptfilter AcceptEx() is supported with AcceptFilter data, or connect, per the documentation. AcceptEx() is not used for AcceptFilter none.
Windows 2.3.13 :: Win32DisableAcceptEx
The widely used Win32DisableAcceptEx is not anymore in 2.3. Can someone confirm that this has the same effect: AcceptFilter http none AcceptFilter https none Maybe an idea to update the upgrading docu on this subject ? Steffen
Re: Windows 2.3.13 :: Win32DisableAcceptEx
On 7/4/2011 9:46 AM, Steffen wrote: The widely used Win32DisableAcceptEx is not anymore in 2.3. Can someone confirm that this has the same effect: AcceptFilter http none AcceptFilter https none Maybe an idea to update the upgrading docu on this subject ? http://httpd.apache.org/docs/2.3/mod/core.html#acceptfilter AcceptEx() is supported with AcceptFilter data, or connect, per the documentation. AcceptEx() is not used for AcceptFilter none.
Re: Win32DisableAcceptex
pe, 2004-04-16 kello 23:04, Sami Tikka kirjoitti: Of course, the easy way out is to just increase the number of threads/processes, but then the question is how many threads/processes are enough to handle all HTTP CONNECTs and still have plenty to spare to handle plain HTTP traffic. I think the dedicated handler for HTTP CONNECTs would make more sense. Or would it be a really bad idea? It just occurred to me that perhaps the easiest workaround would be to make the number of threads variable in mpm_winnt. The other mpms seem to be able to create/destroy threads or processes as they go along. The windows mpm uses a fixed number of threads. Why is that? Is there some architectural limitation behind the design? -- Sami
Re: Win32DisableAcceptex
It seems I have tracked down the problem plagueing my client. It seems it has absolutely nothing to do with AcceptEx(). AcceptEx() is reporting errors because the previous proxy is aborting idle connections that Apache has not replied to in 150 seconds. That is causing the specified network name is no longer available errors. The real problem is why Apache does not handle those connections and it is because Apache is out of free threads. All of its threads are busy handling HTTP CONNECT methods (Apache was running as a proxy, remember). It seems that SSL connections are extremely long-lived, I have seen them last as long as 300 seconds. Also, mod_proxy_connect.so does not have any timeout code in it. The tunnel will be open until someone else closes it. (This may be how it is supposed to work, I'm not that familiar with SSL and HTTP CONNECT.) However, it seems to me that dedicating a thread or a process to run in a tight while-loop copying bytes back and forth between 2 sockets is an overkill. Would it be possible to have a dedicated thread/process for that and mod_proxy_connect would not handle the request itself, (perhaps create the backend connection) only pass the 2 sockets to the dedicated thread/process. Of course, the easy way out is to just increase the number of threads/processes, but then the question is how many threads/processes are enough to handle all HTTP CONNECTs and still have plenty to spare to handle plain HTTP traffic. I think the dedicated handler for HTTP CONNECTs would make more sense. Or would it be a really bad idea? -- Sami Tikka tel: +358 9 2520 5115 Senior Software Engineerfax: +358 9 2520 5013 F-Secure Corporationhttp://www.f-secure.com/ BE SURE
RE: Win32DisableAcceptex
-Original Message- From: Bill Stoddard [mailto:[EMAIL PROTECTED] Please double check then check again. This sounds a lot like a dynamic ip address issue. The machine is using static IP address but the DHCP service was also running. I disabled it but the hang with WSAEHOSTDOWN error still occurs every few hours. The listener is opened in the parent and inheritied by the child process. I would say the listening socket is still ok if the hang recovers after a period of time. Try running apache in one process mode (apache -DONE_PROCESS). I have no idea if the server will hold up under load in one process mode because I've not tested it recently, however if it does and the hang does not occur, it gives us a real big hint that the problem may be in the Windows kernel related to the listening socket being inherited. Actually, apache is running with -DONE_PROCESS at my client's. That is because I wanted to be able to detect and report any possible crashes. So it is not an issue with socket inheritance. I have also made a small patch that checks if the GetOverlappedResult() in winnt_accept() fails, apache logs the error and calls exit(). This seemed to help the customer quite a bit. Usually the the newly started apache instance also got this problem and exited but after 3 or 4 new restarts the hang was over and apache operated normally. I was wondering if it would help to just close the listening socket and createbindlisten a new one instead of doing a full-blown restart. Of course, now that I know the listening socket is normally inherited from the parent process, I think closing it and making a new one might be very tricky... Perhaps a graceful restart would be enough but there was no way to initiate that from the child process, right? -- Sami
RE: Win32DisableAcceptex
At 05:10 AM 3/29/2004, Tikka, Sami wrote: -Original Message- From: Bill Stoddard [mailto:[EMAIL PROTECTED] Please double check then check again. This sounds a lot like a dynamic ip address issue. The machine is using static IP address but the DHCP service was also running. I disabled it but the hang with WSAEHOSTDOWN error still occurs every few hours. Actually, apache is running with -DONE_PROCESS at my client's. That is because I wanted to be able to detect and report any possible crashes. So it is not an issue with socket inheritance. Good to know! I have also made a small patch that checks if the GetOverlappedResult() in winnt_accept() fails, apache logs the error and calls exit(). This seemed to help the customer quite a bit. Usually the the newly started apache instance also got this problem and exited but after 3 or 4 new restarts the hang was over and apache operated normally. Good solution - for parent/child setups we ximply need to exit with a specific AP_ERROR_NETRESET code to tell the parent to recreate the listeners. I was wondering if it would help to just close the listening socket and createbindlisten a new one instead of doing a full-blown restart. You cant - thats why Apache is structured with a parent/child setup. Although it's 1:1 now, we have plans to go 1:many - the child cannot create the listen socket. Of course, now that I know the listening socket is normally inherited from the parent process, I think closing it and making a new one might be very tricky... Perhaps a graceful restart would be enough but there was no way to initiate that from the child process, right? Of course - child exit()s. But if you don't want to wait - we need another custom service signal (we use 128 (?) for graceful, so use 129 to signal that the network listeners are borked and do a graceful w/ fresh sockets.
RE: Win32DisableAcceptex
Rather than talk about what the name of the directive is, I'd like to raise the issue does workaround involved really work or not. I have a customer who runs a lightly loaded W2K server with Apache 2.0.45 + selected patches and every couple of hours it hangs for 10-15 minutes and then magically recovers. During the hang the error.log is filled with Fri Mar 12 11:50:52 2004] [warn] (720064)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. I have taken the Win32DisableAcceptEx patch from 2.0.49 and it did not help. It no longer complains, but it still hangs. The customer used to run MS ISA server in the same box but the hang also happens consistently on a plain-vanilla W2K server with nothing else than Apache installed. No dynamic IP address, no dynamic DNS, no QoS packet scheduler... As plain as I can make it. I notice in mpm/winnt/child.c that upon failing at AcceptEx, the accepted socket is closed, a new one is created and AcceptEx is retried. Has it helped anyone? Would a more effective strategy be to close the listening socket and create a new one? Has anyone tried that or considered that? Can someone point out to me if it is a bad idea? If not, I'm about to try that because I'm running out of ideas... -- Sami Tikkatel. +358 9 2520 5115 senior software engineer fax. +358 9 2520 5014 mobile +358 40 7379388 F-Secure Corporation http://www.f-secure.com BE SURE
Re: Win32DisableAcceptex
Tikka, Sami wrote: Rather than talk about what the name of the directive is, I'd like to raise the issue does workaround involved really work or not. I have a customer who runs a lightly loaded W2K server with Apache 2.0.45 + selected patches and every couple of hours it hangs for 10-15 minutes and then magically recovers. During the hang the error.log is filled with Fri Mar 12 11:50:52 2004] [warn] (720064)The specified network name is no longer available. : winnt_accept: Asynchronous AcceptEx failed. I have taken the Win32DisableAcceptEx patch from 2.0.49 and it did not help. It no longer complains, but it still hangs. The customer used to run MS ISA server in the same box but the hang also happens consistently on a plain-vanilla W2K server with nothing else than Apache installed. No dynamic IP address, no dynamic DNS, no QoS packet scheduler... As plain as I can make it. Please double check then check again. This sounds a lot like a dynamic ip address issue. I notice in mpm/winnt/child.c that upon failing at AcceptEx, the accepted socket is closed, a new one is created and AcceptEx is retried. Has it helped anyone? The listener is opened in the parent and inheritied by the child process. I would say the listening socket is still ok if the hang recovers after a period of time. Try running apache in one process mode (apache -DONE_PROCESS). I have no idea if the server will hold up under load in one process mode because I've not tested it recently, however if it does and the hang does not occur, it gives us a real big hint that the problem may be in the Windows kernel related to the listening socket being inherited. Bill
Win32DisableAcceptex
Didn't we decide in the move to 2.0 that all directives would take an argument? Win32DisableAcceptex seems to work just by being present in the config with no argument. Shouldn't it instead be Win32DisableAcceptex on|off Joshua.
Re: Win32DisableAcceptex
Joshua Slive wrote: Didn't we decide in the move to 2.0 that all directives would take an argument? Maybe I wasn't paying attention. Win32DisableAcceptex seems to work just by being present in the config with no argument. True. Shouldn't it instead be Win32DisableAcceptex on|off To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but it makes sense. Joshua. Bill
Re: Win32DisableAcceptex
On Mon, 22 Mar 2004, Bill Stoddard wrote: Joshua Slive wrote: Didn't we decide in the move to 2.0 that all directives would take an argument? Maybe I wasn't paying attention. As far as I know, there are no other directives in httpd-2.0 that act this way. But I may be mistaken. Shouldn't it instead be Win32DisableAcceptex on|off To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but it makes sense. I guess then it should be Win32EnableAcceptex on|off with on the default. But I guess I am too late for this discussion since we released it in 2.0.49 and changing it now would break compatibility. Joshua.
Re: Win32DisableAcceptex
* Bill Stoddard [EMAIL PROTECTED] wrote: Joshua Slive wrote: Didn't we decide in the move to 2.0 that all directives would take an argument? Maybe I wasn't paying attention. Win32DisableAcceptex seems to work just by being present in the config with no argument. True. Shouldn't it instead be Win32DisableAcceptex on|off To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but it makes sense. So what can we do? Change it in 2.1 to EnableAcceptEx On|Off (default on)? nd
Re: Win32DisableAcceptex
At 08:42 AM 3/22/2004, Bill Stoddard wrote: Shouldn't it instead be Win32DisableAcceptex on|off To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but it makes sense. or easier to parse and consistant w/ mmap/sendfile; EnableWin32AcceptEx on|off [default: on if supported] You might leave the Win32DisableAcceptEx as is, for 2.0 - in case users add that directive in the coming weeks. But I would mark it deprecated already and add the EnableFoo flavor for consistancy. Bill
Re: Win32DisableAcceptex
William A. Rowe, Jr. wrote: At 08:42 AM 3/22/2004, Bill Stoddard wrote: Shouldn't it instead be Win32DisableAcceptex on|off To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but it makes sense. or easier to parse and consistant w/ mmap/sendfile; EnableWin32AcceptEx on|off [default: on if supported] You might leave the Win32DisableAcceptEx as is, for 2.0 - in case users add that directive in the coming weeks. But I would mark it deprecated already and add the EnableFoo flavor for consistancy. Bill +1 Bill
