I can reproduce the first case with the installer, pretty much ondemand
using our installer stuff. I've tried reproducing it by ripping out the
actions that do the Runtime.exec() to call httpd.exe into a separate
standalone program, and the problem doesn't occur there. Go figure.
But when this occurs httpd.exe is unresponsive to localhost AND remote
traffic immediately. I think I can get one or maybe 2 requests in and
out before it additional connections simply hang until a network
timeout. Wireshark shows the request is ACKed but that's it.
My initial thought was that something cause the process to be blocked,
but from what I can tell from Process Explorer/Process Monitor the
threads look correct and are simply waiting for a request.
The internet explorer 11 case, I've not seen myself, just from reports
of other developers I've worked with. It occurs from automated tests,
and these are mostly remote clients running IE11.
Andy
On 06/10/2015 03:52 PM, William A Rowe Jr wrote:
Can you reproduce using the real network driver? The loopback/localhost
interface is famously junk.
On Jun 10, 2015 11:22 AM, "Andy Wang" <aw...@ptc.com
<mailto:aw...@ptc.com>> wrote:
Yeah, that much I more or less get.
What I really don't understand is what can a client do (IE11) that
would regularly cause httpd.exe to hang with AcceptEx. This is
reproducible on every single machine I've ever tried, including
completely vanilla virtual machines, or pretty straightforward
physical machines with intel NICs and no additional stack drivers.
That seems like a pretty hideous architecture if a regular
non-malicious client requests could end up causing the web server to
simply stop responding.
The InstallAnywhere problem I mentioned is also reliably reproduced
on every single Windows system I've tried this on (about a dozen
different systems with different configurations - virtual and
physical). This is the one I especially can't understand. How
would launching httpd.exe from a installer process (java.exe
specifically) prevent it from responding to requests.
Andy
On 06/10/2015 10:48 AM, William A Rowe Jr wrote:
It turns off all advanced socket mechanics for accepting
connections.
That means
it won't pre-fetch data. Because of how cobbled-together the
WinSock
network
stack drivers (third parties, included) were, there are many
things that
break
sendfile (disable sendfile) or socket reuse (disable advanced
accept logic).
In other words, if you need reliability on some pretty crazy
installations of
Windows with lots of out-of-date drivers, your solution is the
way to
go. They
are for performance, there is no reason to turn these on in
low-traffic
cases.
On Wed, Jun 10, 2015 at 10:31 AM, Andy Wang <aw...@ptc.com
<mailto:aw...@ptc.com>
<mailto:aw...@ptc.com <mailto:aw...@ptc.com>>> wrote:
I originally asked this on user@httpd and didn't get a
response, so
thought I'd redirect to dev and see if anyone can explain
why this
would occur if you have time. I have to admit, it's a
curiosity to
me, that I just don't want to let go until I understand it
and what
research I've done into AcceptEx doesn't seem to be giving
me any
more insight.
--- original message ---
We've come across numerous cases where apache httpd 2.4
(I'm using
2.4.12 but I don't believe this is version specific) hang
using the
default configuration options.
There are two cases
1) we have an InstallAnywhere installer that launches httpd
during
install time to do some initial work. When the installanywhere
installer starts httpd.exe (it does it via cmd.exe) httpd
does not
respond to requests. If you kill the installanywhere
installer, then
all of the sudden httpd starts responding
2) certain IE 11 client requests hang httpd 2.4.
I've wireshark'ed #2 and at some point, an http GET gets an
ACK and
nothing more. I've peeked a little bit at the process
threads with
processexplorer (unfortunately i'm not a windows developer,
so I'm not
entirely familiar with the low level windows stuff) and
everyhting looks
like it's okay and simply waiting for requests.
What I found after googling and testing is AcceptFilter
http|https none
prevents both of those problems. I've not yet tried
connect to see if
that works either.
But what I'm really wondering about is, can anyone explain,
especially
in #2, what it is about AcceptFilter http none that
actually resolves
these types of issues?
Thanks,
Andy
