On 06/10/2015 09:46 PM, William A Rowe Jr wrote:
On Wed, Jun 10, 2015 at 4:12 PM, Andy Wang <aw...@ptc.com
<mailto:aw...@ptc.com>> wrote:
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.
This sounds like a permissions problem.
Pleading windows ignorance here, but what kind of permissions problem?
Both processes are elevated to administrator via UAC (or with UAC
disabled) and literally as soon as you kill the parent java.exe process,
it starts to work.
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.
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.
It is possible that the 'data' mode (that ships the first packet(s) into
buffers upon receiving data) is somehow incompatible with a broken IE11
handshake.
Yeah, i wish this was reproducible more on demand so I can grab the
packet capture.
