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
, 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
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
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
Win32DisableAcceptEx to mpm_winnt doc? Or even add it
back in as a directive to point to AcceptFilter?
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
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
-- 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
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
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
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
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. :
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. :
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
(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
,
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
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
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
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
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
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
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
-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
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
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
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
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.
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
.
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
* 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
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
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
32 matches
Mail list logo
