Yep, confirmed, it accepts connection but never responds. Its a web front end to an LDAP server. The web server accepts the connection and then goes off to talk to the LDAP server. Attempts to talk directly to the LDAP server through the pipeline timeout, so I suspect the web server is having the same thing happen and for some reason doesn't see fit to tell me about it, leaving me hanging there (which is pretty nasty behavior imo).
Assume for the sake of discussion thats an accurate diagnosis.What would I need to do to my pipeline to get it to actually stop waiting after a reasonable amount of time? TcpClient's TimeOut apparently doesn't do that in this circumstance. Or am I all wet? -- bc On Mon, Apr 20, 2015 at 3:54 PM, Rob van der Heij <[email protected]> wrote: > > The nasty thing is that when I do not get a response (i.e. there's no > > output at all from TcpClient), the pipe sits there waiting forever, > despite > > the 30 second timeout. > > > > I've no clue why. > > > > Ideas? > > -- > > bc > > > > You could verify by running with "listrc" to see what was keeping the pipe > from terminating. But it's very will possible tcpclient is the one. If it's > the decoding segments after it, you might want to look at 'httpsplit' to > decode the response. > > It likely depends on how the server misbehaves. When the server starts to > respond but never finishes to say what you expect, then things will be > sitting there. If you know you expect the conversation finished in 30 > seconds, you might have to add a time bomb yourself. > > Rob >
