Tonight my fellow Tellago-ans, and I ran into a issue using the WCF-CustomIsolated Adapter on Windows Server 2008 64bit.
We were trying to use the .Net 3.5 bindings/REST styled architecture to support HTTPv1.1 Posts into BizTalk using the WCF CustomIsolated Adapter. In our lab and development environments, process worked like a charm. We used HTTP Fiddler to test the data and message flow. Here’s an example of what I mean:
In the above screen shot, we have configured a WCF-CustomIsolated adapter to use the .Net 3.5 WebHTTPBinding. (Instructions on how to do this can be found in Adrian’s blog). When using Fiddler, we can easily make posts into the BizTalk Server:
And our response we would receive would be something similar to this:
However upon moving our solution to a 64bit BizTalk Server running on IIS 7.0 (64bit Mode), the HTTP Post no longer worked. We started receiving “504” gateway issues.
Now oddly enough these servers were behind a firewall; we did need VPN accounts and software to access these servers; and also to mention, to get any internet access we went through a web proxy. This would lead any logically thinking person to believe the problem lie in one of these culprits: Firewall, VPN, or proxy…
Not so fast says the turtle!!!
Well, we started looking more into this and turned on WCF Tracing and looking into the Event Viewer and saw that we were receiving a weird WCF error. The error was:
The adapter “WCF-CustomIsolated” raised an error message. Details “System.XmlXmlException: Unexpected end of file.
At System.Xml.EncodingStreamWrapper.ProcessBuffer(Byte[] buffer, Int32 offset, Int32 count, Encoding encoding)…
(and on and on…)
We did not have a malformed message, after all it was Http Fiddler and we were just typing in a dummy xml message like “<Blah/>” and the WCF Adapter was failing horribly on the 64bit machine, where as the 32bit machine ran like charm… We started to think maybe it was an encoding issue, or something…
So Here’s the WTF for the day!!!
It turns out the issue lie in the fact that the WebHttpBinding element by default utilizes the transferMode set to Buffered.
Apparently there is an issue when trying to use this setting on a win64 bit OS, with IIS 7.0 in 64bit mode, with BizTalk WCF-CustomIsolated adapters… Our fix:
You guessed it: set the transferMode property to Streamed issue resolved.
D Goins Insperience 