Ernst Wolthaus

There is a setting of max request lenght in machine.config.
<httpRuntime .... maxRequestLength="4096" ..../>
MaxRequestLength : KBytes size of maximum request length to accept


Please modify this value and try again.

I ran into the same problem so I reverted back to the good old HTTPRequest
object. I understand that this is not the approach u wanted to take but it
works - I am uploading 200M+ file to a web service using this method.
Here is a code snippet:

HttpWebRequest request = WebRequest.Create(_svc.Url) as HttpWebRequest;
request.Method = "POST";
request.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services
Client Protocol 1.1.4322.2032)";
request.Timeout = 4000000; // approx. 1hour
request.ContentType = "text/xml; charset=utf-8";
request.Headers.Add(action);
request.AllowWriteStreamBuffering = false;
request.SendChunked = true;

Of a particular interest are the last two properties of the request obj.
This will make sure you are submitting the chunks without buffering them
first.
Also, I added the following in the web.config file of the webservice:
<configuration>
.
.
<system.web>
.
.
.
<httpRuntime
maxRequestLength="1500000"
executionTimeout="1800"
useFullyQualifiedRedirectUrl="false"
minFreeThreads="8"
minLocalRequestFreeThreads="4"
appRequestQueueLimit="100"
/>

Hmm Ernst,

As usual I should have read your post better. You already found the solution by modifying the machine config.

But i was thinking maybe it's possible to use other transport methods.

Why not (just) write to the file system and have bizTalk pick it up with the file adapter or FTP adapter.....or whatever.....

Dime will get a bit complicated but you could try using WS-Compression. If the data is text/xml then this will make your message utterly small. It depends who is gonna do what with your message parts.

I almost always choose the create smaller messages. Just try comparing it with normal network packages. You have a big piece of data to transfer but it gets fragmented by the network stack.

The cool thing of msmq is is that you can poll queue messages for priority and also FIFO. Both concepts just don't work with ugly BTS because what it does first is pump all messages into its own messagebox where it looses all this meta-information.