CODEWITHSUNDEEP
biztalkbiztalk-2013r2
Dijkgraaf
Dijkgraaf

Reputation: 11527

What are the implications of enabling the Default application domain for isolated adapter in BizTalk?

We recently encountered the following error in BizTalk

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.PassThruReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “Unknown ” Receive Port: "CustomerAPI" URI: "/Service.svc" Reason: Attempted to access an unloaded AppDomain.

Researching this error led us to Known Issues with the SOAP Adapter which said.

The default AppDomain hosting the SOAP adapter gets unloaded causing the host process to hang

Problem:

The process hosting the SOAP adapter hangs, causing all other Web services in the process to hang. This may result in the following error: There was a failure executing the response(send) pipeline: "Unknown " Source: "Unknown " Receive Port: TwoWayLatencyLoopBack_RxPort" URI: "/TwoWayLatencyRxSOAP/TwoWayLatencyWS.asmx" Reason: Attempted to access an unloaded AppDomain.

Cause

The SOAP adapter runs in the IIS process space. If more than one Web service exists in the IIS AppPool, then every Web service ends up having its own AppDomain.

By default all messaging engine objects are created in the first AppDomain (that is,. the AppDomain corresponding to the first Web service). If the first Web service is inactive for an extended period of time for any reason, IIS unloads the first AppDomain. When this happens, all services in the hosting process become unusable.

Resolution

To prevent the AppDomain from being unloaded, follow the procedure below:

  1. Click Start, point to All Programs, point to Microsoft BizTalk Server and then click BizTalk Server Administration.

  2. In BizTalk Server Administration Console, Expand BizTalk Server Administration, expand BizTalk Group, expand Platform Settings, and then click Hosts.

  3. From the list of Hosts, right-click the required host, and then click Settings.
  4. In the BizTalk Settings Dashboard, check Default application domain for isolated adapter under General tab.

When you do this, the BizTalk Messaging Engine objects are created in the default AppDomain instead of in their own AppDomains. Because the default AppDomain is never unloaded, the problem no longer occurs.

Below is a screenshot of that setting.

enter image description here

We enabled this setting in a Test environment and noticed that a memory usage and a memory leak was reduced, see Mark Brimble's blog BizTalk Host Settings – “Default application domain for isolated adapter” for further details.

Are there any disadvantages to enabling the Default application domain for isolated adapter setting or what other impacts would enabling this setting cause in BizTalk?

If there are no disadvantages, why isn't this on by default for all Isolated Hosts?

Upvotes: 2

Views: 381

Answers (1)

Dan Field
Dan Field

Reputation: 21661

Executing in separate AppDomains should make things more secure with regard to the boundaries set up between them. It also makes it easier for IIS to free/release resources without restarting the whole process - if a particular service/site isn't in use, its AppDomain can be torn down more cheaply than restarting w3wp.exe.

However, it seems like in this case BizTalk tries to have it both ways - allow IIS to manage security/memory/assembly loading better by using multiple AppDomains, but also just keep using the default one no matter what when a message request comes in. This seems like a design flaw, which makes it hard to see when you'd ever want to leave that setting unchecked.

Upvotes: 1

Related Questions