Partager via

Important hotfix if you are running in OutOfMemoryException with Orchestration Host

  • Article

I have seen many BizTalk customers running into OutofMemory Exception while calling a map from inside the Orchestration, so I thought this blog post should help.

Typically, this happens when we are calling a map from inside the Orchestration and the map is inside a large assembly. This was a known issue and was documented at https://support.microsoft.com/kb/918643

“The System.Policy.Security.Evidence object is often used in transforms and can consume much memory. Whenever a map contains a scripting functoid that uses inline C# (or any other inline language), the assembly is created in memory. The System.Policy.Security.Evidence object uses the object of the actual calling assembly. This situation creates a rooted object that is not deleted until the BizTalk service is restarted.

Most of the default BizTalk functoids are implemented as inline script. These items can cause System.Byte[] objects to collect in memory. To minimize memory consumption, we recommend that you put any map that uses these functoids into a small assembly. Then, reference that assembly.”

So for example if you have got the map inside a 10 MB Assembly, it will always create 10 MB System.Byte[] objects in the memory and you can imagine how quickly you could run into the OOM Exception if you are on a 32 bit environment. Earlier only workaround was to put map in the small assembly but if you are not able to split the maps and other artifacts by different project, then the good news is that this issue is fixed in https://support.microsoft.com/?id=975118.

This hotfix has been released for BizTalk 2006, BizTalk 2006 R2 and BizTalk 2009. Also, this hotfix is part of BizTalk 2006 R2 SP1.

I have seen that this hotfix improves memory utilization by the orchestration hosts. This also helps increase performance and stability of the BizTalk applications. If you haven’t got this fix as of yet, I will highly recommend to apply this fix ASAP.

Comments

  • Anonymous
    September 06, 2010
    thanks for sharing this mate ....