PRB: You May Encounter Delays When You Are Running Multiple XLANG Schedules That Are Using Correlation

When an XLANG schedule is using correlation:

• Significant delays may occur in the time that it takes to complete multiple schedules.
• The data instance that is being correlated may be moved to the suspended queue.

This behavior may occur if:

• The XLANG schedule is configured to run in a pool.
  
  -and-
• The number of XLANG schedule instances for that pool exceed the schedule pool size.

To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: To optimize the performance of XLANG schedules that use correlation, use any of the following methods:

• Reduce the COM+ pool creation time from 30 seconds.
• Increase the COM+ pool Max thread.
  
  NOTE: There is no formula to calculate the perfect pool size.
• Increase the retry interval.
• Increase the number of BizTalk worker threads.
• Use a common queue instead of per-instance queue correlation.
  
  NOTE: For additional information, review the XLANG Correlation sample in BizTalk Server 2002.

Additional Workaround

Try to modify the receiving channel or port from an adapter, such as the Microsoft BizTalk Adapter for MQSeries, to place all incoming documents into a Microsoft Message Queuing queue so that the XLANG schedule can then refer to this named queue for incoming documents. As a result:

• Correlation messages can be serviced by the BizTalk Messaging worker threads.
  
  -and-
• The worker threads are freed from processing incoming documents.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 3.

All documents that BizTalk Messaging will be processing start out in the BizTalk Work Queue. When the BizTalk Messaging engine is processing an XLANG schedule, the BizTalk Messaging engine uses worker threads to pull the XLANG schedules from the BizTalk Work Queue. When these XLANG schedules are set to use the COM+ XLANG schedule pool, the worker thread that is processing the XLANG schedule runs according to the settings for the specific COM+ XLANG schedule pool that is set in the schedule.

The number of the messages that BizTalk Messaging will be processing depends on the COM+ pool size and the number of XLANG schedule instances that are running. When the number of messages in the work queue that are destined for the XLANG schedule exceeds the pool size, the BizTalk worker threads block while attempting to service the Work Queue. The worker threads are blocked waiting for the running schedules to complete. As a result:

• Any messages that include correlation messages are not delivered to a running XLANG schedule instance in a timely manner.
  
  -and-
• The running XLANG schedule may eventually be moved to the suspended queue because there are worker threads available to handle the incoming correlation message.