WCF client hangs on big response: make it streamed

I have to blog about this - as I spent a few days having nightmares about it.

An operation from a websphere service was returning a pdf string, for a payload of about 500KB. The WCF client consuming the service was working fine on the test fixture, but when the operation was integrated in the web solution, with the exact same binding and endpoint, the client was hanging for more than a minute onto the response of this particular operation (every other operation with a smaller payload was OK) before coming back with the deserialized response.

I initially blamed the service, but then noticed (sniffing traffic via fiddler) the response was coming back quick enough and only then the client would hang for more than a minute obviously trying to deserialize or God knows what.

After quite a bit of hacking around on and off, I managed to change the transportmode config setting on the binding from buffered to streamed (I had nothing else left to try!), and it did the trick. In light of this it's pretty obvious that the response was being chunked in parts the size of the buffer and that was probably slowing down the whole process.

Morale of the story: if you've got big payloads transportMode="Streamed" could save your sorry ass.

CWWSS7200E: Unable to create AxisService from ServiceEndpointAddress

This is what I got back when I tried to bounce a JAVA WebSphere Axis service from a WCF client:

CWWSS7200E: Unable to create AxisService from ServiceEndpointAddress

Took me a while but eventually figured out what was wrong and ,long story short, WebSphere did not like the HttpHeaders generated by the WCF bindings (basicHttpBinding) when sending the request.

I started sniffing traffic with Fiddler, but initially I was paying attention only to the SOAP envelope. I then tried to directly invoke the service using SoapUI and it basically seemed to work fine (no Unable to create AxisService error message and I was getting back the result I expected). With the SOAP envelope ruled out, the next logical consequence needed to be the HttpHeader, so I compared the header generated by WCF with the one automatically generated by SoapUI (by pointing the tool to the endpoint url):

WCF Generated HttpHeader:

POST /MyWebServiceDomain/aWebService HTTP/1.1

SoapUI Generated HttpHeader:

POST http://xx.xxx.xxx.xx:9080/MyWebServiceDomain/aWebService HTTP/1.1

At this point it was fairly obvious that I needed to tweak the POST line of the HttpHeader to include the full definition of the endpoint, hopefully by WCF configuration - and after asking around a co-worker pointed me in the right direction: hostNameComparisonMode="Exact" on the WCF binding is what I was looking for (it seems to be set to StrongWildcard by default).

Couldn't find anything on the web about any of the above - I hope this helps someone else with the same problem.

Add Service Reference duplicates properties on Faults

Spent the last few days fighting with this, finally found what seems to be a workaround so I thought I'd share hoping that it can be of some use to some other poor devil who's stuck.

Dealing with WebSphere generated web services, the curious occurrence of duplicate properties on Faults (on different partial classes) was encountered when generating proxies through add service reference on Visual Studio 2008, pretty much in a very similar way as described in this post on the msdn forum.

Solution: Long story short, you have to use svcutil to generate your proxy classes and data types with the /useSerializerForFaults attribute, this will cause the XmlSerializer to be used for reading and writing faults (but only those), instead of the default DataContractSerializer (which will still be used for the rest of the stuff).

Note 1: using the option /serializer:XmlSerializer instead of /UseSerializerForFaults on svcutil will cause the Faults to be wrapped in a sub-namespace (the same namespace they were defined in the xsd contract).

Note 2: setting the corresponding option item UseSerializerForFaults to false in the ServiceMap file does not give the same results (instead of generating duplicated properties it started generating duplicated attributes, two on each partial class).

This seems to be a genuine bug. Let's just hope it gets fixed because it's a pain to import stuff manually.

Note that if you kick it old school and import the service as web reference (the .NET 2.0 way) it should work fine as well, but for me this was not a choice.