On Thu, Jun 11, 2015 at 11:09 AM, Andy Wang <aw...@ptc.com> wrote: > > On 06/11/2015 09:02 AM, William A Rowe Jr wrote: > >> >> Sounds telling. Can you get your installer to stall without invoking >> httpd.exe - and then attempt to start httpd outside of the installer on >> the same machine? Something going on within the installer may be >> interacting with the winsock stack. If so, with the installer frozen >> the problem should occur outside of the installer process, I'd expect. >> >> > The installer never actually stalls either. it continues to process a few > things and then eventually it needs to make a request to httpd to make sure > it's up. At that point, the installer hangs waiting for response. the > interesting thing is the TCP handshake and GET request are both actually > completed, so there's no other timeout. So the process primary thread is > "hung" because of that. However all other threads are perfectly fine (JMX > monitoring can connect to it, i can get jstack thread dumps, etc etc) > > The only thing that appers to be hanging is httpd.exe but even then it's > not hung in the sense that anything is blocked.. processexplorer/monitor > show everything to be simply waiting for requests that the windows tcp > stack simply isn't passing to it.
Got all that, I suggested you stall it deliberately. Comment out invocation of httpd.exe; then put a 20 minute 'sleep' in the installer logic when it would typically query the browser. While running the installer package, now try using httpd.exe with the same config, etc outside of the installer entirely, and see if it responds. This will indicate if there is something in the installer that has messed up the network stack. > One of the other windows guys here, theorized that it has to do with >> inherited handles but he couldn't really work out why. He's not a >> winsock expert though. >> >> >> A possibility. There is the -X (-DONE_PROCESS) startup flag to rule >> that out. >> >> > If I get some free time, I nmight try to reproduce this and document some > of the above thread analysis. It's not ahuge problem for me. We've been > deploying httpd 2.2.x with Win32DisableAcceptEx configured the whole time. > When I migrated to 2.4.x I didn't move tha tforward to the Acceptfilter > configuration because i didn't know for sure why we needed it and i > thought, hey new httpd.exe version, why not try and see what happens. > Yes, AcceptFilter none is semantically identical to Win32DisableAcceptEx. Otherwise, AcceptEx() is used in one of two different modes to ensure that a packet of data was received before signalling httpd that a connection is established.
