WCF client hangs on response

Question

I have a WCF client (running on Win7) pointing to a WebSphere service.

All is good from a test harness (a little test fixture outside my web app) but when my calls to the service originate from my web project one of the calls (and only that one) is extremely slow to deserialize (it takes minutes VS seconds) and not just the first time.

I can see from fiddler that the response comes back quickly but then the WCF client hangs on the response itself for more than a minute before the next line of code is hit by the debugger, almost if the client was having trouble deserializing. This happens only if in the response I have a given pdf string (the operation generates a pdf), base64 encoded chunked. If for example the service raises a fault (thus the pdf string is not there) then the response is deserialized immediately.

Again, If I send the exact same envelope through Soap-UI or from outside the web project all is good.

I am at loss - What should I be looking for and is there some config setting that might do the trick?

Any help appreciated!

EDIT:

I coded a stub against the same service contract. Using the exact same basicHttpBinding and returning the exact same pdf string there is no delay registered. I think this rules out the string and the binding as a possible cause. What's left?

Answer 1

I have had this bite me many times. Check in your WCF client configuration that you are not trying to use the windows web proxy, that step to check on the proxy (even if there is not one configured) will eat up a lot of time during your connection.

Answer 2

First things to check:

• Is the config the same in the web project and the test project?
• When you test from SOAP UI are you doing it from the same server and in the same security context as when the code is running from the web project. -Is there any spike in the memory when the pdf comes back?

Edit

From your comments the 1 min wait, appears that it is waiting for a timeout. You also mention transactions.

I am wondering if the problem is somewhere else. The call to the WCF service goes OK, but the call is inside a transaction, and there is no complete or dispose on the transaction (I am guessing here), then the transaction / code will hang for 1 min while it waits to timeout.

Edit 2

Next things to check:

• Is there any difference in the code is the test and in the web project, on how the service is being called.
• Is there any differnce in the framework version, for example is one 3.0 and the other 3.5

Answer 3

If the tips of the other users don't help, you might want to Enable WCF Tracing and open it in the Service Trace Viewer. The information is detailed, but it has enabled me to fix a number of hard-to-identity problems in the past.

More information on WCF Tracing can be found on MSDN.

Answer 4

Can it be that client side is trying to analyse what type of content is coming from server side? Try to specify mime type of the service response explicitly on the server side, e.g. Response.ContentType = "application/pdf" EDIT: By client side I mean any possible mediator like a firewall or a security suite.

Answer 5

Two thing you can try:

1. Adjust the readerQoutas settings for your client. See http://msdn.microsoft.com/en-us/library/ms731325.aspx

2. Disable "Just My Code" in debugging options. Tools -> Options -> Debugging -> General "Enable Just My Code (Managed only)" and see if you can catch interal WCF exceptions.

//huusom

Answer 6

Changing transferMode="Buffered" into transferMode="Streamed" on the binding did the trick!

So the payload was apparently being chunked in small bits the size of the buffer.

I thought the same could have been achieved by increasing the buffersize (maxBufferSize="1000000") but I had that in place already and it did not help.

Answer 7

I had the very same issue... The problem of WCF, IMO, is in the deserialization of the base64 string returned by the service into a byte[] client side.

The easiest to solve this if you may not change your service configuration (Ex.: use a transferMode="Streamed") is to adapt your DataContract/ServiceContract client side. Replace the type "byte[]" with "string" in the Response DataContract.

Next simply decode the returned string yourself with a piece of code such as:

byte[] file = Convert.FromBase64String(pdfBase64String);

To download a PDF of 70KB, it used to required ~6 sec. With the suggested change here above, it takes now < 1 sec.

V.

PS.: Regarding the transfer mode, I did try to only change the client side (transferMode="StreamedResponse") but without improvement...