May 2011 Entries

Part 2 of my "Reloaded-Series"!

In the orginal post here TCPBinding seemed to be the solution. But it is not the best and in some cases just not usable.

This only applies to large requests!

Sabrina and Philippe, both colleagues in the current project, discovered something far better and much more interesting...

What happnes here is DOS-attack-prevention by IIS! Fortunately this did not apply to us that much, sitting behind the DMZ and a far way from the outside world...

Solution: Change the allowed HTTP-request-lenghts... How is this done? One way (and not the worst)

In  the web.config of your WCF-service there are 2 sections to insert the important stuff. At least IIS 7.0 and above.

 <system.webServer>...
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="209715200"/>
      </requestFiltering>
    </security>
  </system.webServer>

  <system.web>...
    <httpRuntime maxRequestLength="2097151" />
  </system.web>

One is legacy (IIS 6....) and the other more today. But both are needed for success.

The numbers are important. "maxRequestLength" is in kb, maxAllowedContentLength in byte. Both are set to very high values in this example. Be careful about that!

You can set some values in IIS but it is not bad practice, I think, to set it on svc-level only...

This error plagued me some time ago but then some change in the called service(i think they sped up processing...) was the solution.

But in my new project it happend again. We call a WebService hostet on WebLogic. No problem if the traffic is low and only few calls are made. But then calls increased and *boom*. Not again! 

It took us several days to tackle it, trying things like the "keepAlive"-customWCF-binding (see earlier post) and lots of config-changes on WebLogic and so on. Nothing seemed to help.

To make a long story short: BizTalk only sends 2 concurrent requests at a time, if not configured otherwise. This leads to some strange behaviour: In the Admin-Console it looks like all the calls actually left the BizTalk-machine. On the receiving side you can see that only 2 connections are actually used (e.g. via netstat). The other calls are kind of queued. If processing is not fast enough on the service-side either a timeout occurs or the dreaded "The request was aborted: The request was canceled.".

Solution (in this case at least...):

Just configure BizTalk to allow more than 2 concurrent calls. How is this done?

http://msdn.microsoft.com/en-us/library/ee290739(BTS.10).aspx

Include the snippet into your BizTalk-Config (BTSNTSvc64.exe.config and/or BTSNTSvc.exe.config depending on the system/hosts you are using. Be sure to choose the correct config!). Here the MS-example:

 <system.net>
    <connectionManagement>
      <add address="www.contoso.com" maxconnection="20" />
      <add address="*" maxconnection="10" />
    </connectionManagement>
  </system.net>
 

And take the advice very seriously that this might lead to flooding target-services... Be careful and set it to the least possible value, that keeps your system running and use the restrictions for the addresses !