ReadResponse() failed: The server did not return a response for this request.
If you have found this Blog entry most likely you are seeing this response in Fiddler. It is accompanied by an HTTP status code of 504. ReadResponse() failed: The server did not return a response for this request is not very helpful and in fact fairly useless in debugging the problem, well short of looking up the exact phrase on Bing or Google to find this blog :).
Successful Response
ReadResponse() failed
I hit this error when trying to return an extremely large set of records via a WCF service today. In fact back at the New York City Code Camp I was asked if WCF could serialize a large dataset into JSON and I started playing at the time. I had sort of forgot about this over the past few months.
Diagnosing the problem involved turning on WCF Tracing and verifying my suspicion that I had hit a default limit. Well the WCF DataContractSerializer has a limit of 65536 object in the object graph. So I did the match on my demo data I was using to work through this issue and yes, I was over that limit in the number of objects. I had a 13 property object and crossing the 5041 record limit caused this issue to surface.
Now back to the ReadResponse() failed issue when using Fiddler. This is my suspicion at this point, so take it for what it’s worth. Based on things I read Fiddler creates this error message in response to a network error, hence the HTTP 504 status code, which is NOT an IIS generated code. It is actually a proxy generated status code and since Fiddler is a proxy this is why you get a 504.
My deduction is the large record set pushes some sort of limit on the network packets and an end of file is missing. Hence Fiddler cannot complete processing of the file stream coming in and promptly throws the proxy error.
Now, how do you deal with large sets of data in the context of JSON, AJAX, WCF, jQuery, etc? Well my suggestion is you don’t. Yes I said it, you don’t. Here is my rational. If you intend to page, sort and filter data in the browser you are wasting your time. It is NOT designed to do this. Yes you can do all that with great performance for small, reasonable sizes of data. But databases were designed to perform these tasks on data, not a JavaScript array sorting algorithm. Instead drive your users to define a much better set of criteria to narrow down the result set. This will give you the ability to reduce the to a manageable size.
I guess how you limit your set of data is up to you. Two strategies that I like are checking the potential size and throwing a ThisIsNotGoingToHappenException to the user so you can let them know they need to do something more to limit the results more. The next is limiting the results to say 500 or 1000 or some other manageable arbitrary size of your choosing and letting the user know there might be more. Either way I think its a good idea to let the user know there is more available, just be more specific. Of course you will have to give them a way to reduce the set.
If you are not having an issue with large responses being sent from the server and you still get the ReadResponse failed error from Fiddler, there is most likely something that is causing a corrupt stream to be sent from the server to the client, Fiddler in this case.