Known Issues with the SOAP Adapter

This section contains information that may help you avoid errors.

Known Issues

The SOAP Adapter experiences poor performance or generates errors under load

Problem

The SOAP Adapter experiences poor performance or generates errors under load

Cause

This problem occurs because the default configuration options for the SOAP adapter or for dependency components that affect the SOAP adapter are not tuned for performance under load.

Resolution

To resolve this problem modify the configuration options for the SOAP adapter or for the dependency components described in the topic Configuration Parameters that Affect Adapter Performance.

The MIME/SMIME encoder and decoder pipeline components cannot encode and decode data processed by the SOAP adapter

Problem

The MIME/SMIME encoder and decoder pipeline components cannot encode and decode data processed by the SOAP adapter

Cause

This problem occurs because the SOAP adapter assembles and disassembles the SOAP messages in the adapter stage of the process.

Resolution

To resolve this problem, Use Secure Sockets Layer (SSL) to secure communications to encode messages processed by the SOAP adapter. On the send side, use the Client Certificate Thumbprint property in the SOAP adapter properties page to achieve this. On the receive side, you must configure the virtual directory that hosts the BizTalk Web Service for SSL secure communications.

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.

The SOAP Adapter fails to register

Problem

The following error may occur when BizTalk Server attempts to register the SOAP (or HTTP) adapter.

"The Messaging Engine failed to register an adapter "SOAP". Details: "Registering multiple adapter types within the same process is not a supported scenario. For e.g. HTTP and SOAP receive adapters cannot co-exist in the same process".

Or

"The Messaging Engine failed to register an adapter "HTTP". Details: "Registering multiple adapter types within the same process is not a supported scenario. For e.g. HTTP and SOAP receive adapters cannot co-exist in the same process".

Cause

When running BizTalk Server on Windows Server 2003 / IIS 6.x, the SOAP and HTTP adapters cannot execute in the same process space or application pool.

Resolution

If an installation requires using both the SOAP and HTTP adapters on the same Web server then separate application pools must be created for each adapter. Once created, the virtual directories for each adapter are each assigned to a different application pool.

See Also

Troubleshooting the SOAP Adapter