+972 52-548-6969
TCP Errors: Tracking it down
time to read 2 min | 226 words
I get to the office this morning, determined to figure out what the hell was going on with my TCP stack. And I can reproduce the error in about 1/3 of the cases.
I know that this is my problem, so I decide to move to a known good version and try to figure out where the error happens. I am doing that, and eventually I get to the head of the repository, without being able to reproduce the error.
After calling for a check of the tooth fairy and requesting immediate assistance from an experienced exorcist, I was unable to reproduce the error, which I found to be really annoying.
I spent some time trying to reproduce that, but couldn't, so I moved to other things.
After an hour, I needed to figure what was going on at the network layer, so I opened Fiddler. A minute afterward I got the same error.
Now I had someone to blame, hurray!
Indeed, it looks like Fiddler isn't quite up to speed for handling large amount of connections in short amount of time. I am not quite sure what is going on there. The scary thing is that I tested that on 4 different machines, and in all cases, I opened Fiddler first to ensure that I knew what was going on.
Comments
so the issue was that you had Fiddler up all the time? (and it wasn't able to keep up)
That is my theory for now, yes.
That could easily be it. The fiddler is great but I have sometimes found it caused disruption with certain types of activity. I think the scenario I came across basically caused it to stop working completely so I didn't have to drive myself crazy looking for problems in my own code. That was a web services type thing too.
Personally I tend to bypass Fiddler these days and go straight for WireShark. Obviously it's less useful when HTTPS is involved, but at least it doesn't introduce another proxy into the equation.
We bypass fidler too, we use a SOAP extension and log all messages to a database, truncate the messages when needed.
Comment preview