Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. FIX: First submitted message takes longer to process than expected after periods of inactivity when you use a BizTalk Server 2010 WCF-Custom adapter

FIX: First submitted message takes longer to process than expected after periods of inactivity when you use a BizTalk Server 2010 WCF-Custom adapter

View products that this article applies to.

Symptoms

Assume that you try to use a BizTalk Server 2010 WCF-Custom adapter to send messages. You set the minimum value (1 second) for the SendTimeout property of the CustomBindingElement object. After some periods of inactivity, the first message submitted may take longer to process in a low-latency environment than expected. Additionally, you may receive an exception that resembles the following:

Description:
Error Message: SOAP Exception description : System.ServiceModel.CommunicationException: An error (The request was aborted: The request was canceled.) occurred while transmitting data over the HTTP channel. ---> System.Net.WebException: The request was aborted: The request was canceled.
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.GetOutputStreamAsyncResult.CompleteGetRequestStream(IAsyncResult result)
--- End of inner exception stack trace ---

Server stack trace:
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)
Timestamp: 26/10/2012 13:59:50
Category: General
Priority: -1
EventId: 10081
Severity: Error
Title:
Machine: Machine Name
App Domain: __XDomain_3.0.1.0_0
ProcessId: 5684
Process Name: Installation Drive:\Program Files (x86)\Microsoft BizTalk Server 2010\BTSNTSvc64.exe
Thread Name:
Win32 ThreadId:11436


↑ Back to the top

Cause

This issue occurs because the common language runtime (CLR) 4.0 begins an operation after 15 seconds that cleans up and terminates any idle IO completion ports until only one port remains. This operation occurs after periods of inactivity before you send messages by using the WCF-custom send port. After a longer period of inactivity, the CLR gate thread (which is partly responsible for creating new IO completion port threads) is also destroyed.

There is a certain way that BizTalk calls into WCF and configures a SendTimeout value in the HttpWebRequest object. To manage this, WCF will use this IO completion port thread to set up an IOThreadTimer class to set a timer that starts if the request is not completed within the time-out period. Then, the thread waits for the timer, and is blocked. However, WCF tries to send the message when it needs another IO completion port. When no IO completion port is available, the CLR must create one together with creating the gate thread. Because of an initial delay between the starting of the gate thread and the gate thread creating an IO completion port thread, the timer that is created by WCF triggers before the IO completion port thread can be created and then read the awaiting data from the socket to be sent.

↑ Back to the top

Resolution

Cumulative update information

To resolve this issue, apply the following cumulative update package. This cumulative update package resolves the issue in the Microsoft.BizTalk.Adapter.Wcf.Runtime.dll component.

For BizTalk Server 2010

The hotfix that resolves this issue is included in cumulative update package 6 for BizTalk Server 2010.

For more information about how to obtain this cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:
2855367 Cumulative update package 6 for BizTalk Server 2010


↑ Back to the top

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

↑ Back to the top

More Information

For more information about delays in IO thread creation, go to the following MSDN blog:

Why Does WCF Become Slow After Being Idle For 15 Seconds?

For information about the service packs and cumulative update list for BizTalk Server, click the following article number to view the article in the Microsoft Knowledge Base:
2555976 Service pack and cumulative update list for BizTalk Server
For more information about BizTalk hotfixes and Service Pack support, click the following article number to view the article in the Microsoft Knowledge Base:
2003907 Information about BizTalk hotfixes and Service Pack support

↑ Back to the top

Keywords: kbqfe, kbfix, kbsurveynew, kbexpertiseadvanced, kb

↑ Back to the top

Article Info
Article ID : 2811803
Revision : 1
Created on : 1/7/2017
Published on : 7/12/2013
Exists online : False
Views : 349