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 : 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_126.96.36.199_0 ProcessId: 5684 Process Name: Installation Drive:\Program Files (x86)\Microsoft BizTalk Server 2010\BTSNTSvc64.exe Thread Name: Win32 ThreadId:11436
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.
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
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
For more information about delays in IO thread creation, go to the following MSDN blog: