BUG: Many Schedules with Ports to MSMQ Prevent Additional Schedules from Being Instantiated (312735)
The information in this article applies to:
- Microsoft BizTalk Server 2000
- Microsoft BizTalk Server 2002
This article was previously published under Q312735 SYMPTOMS
Many schedules that are running or dehydrated may cause high memory usage. This high memory usage may prevent additional schedules from being instantiated due to exhausted system resources. This high level of memory usage only occurs if the schedules contain an MSMQ implementation.
CAUSE
A BizTalk Orchestration schedule that contains an MSMQ implementation or a port to message queuing can claim system resources until the port to message queuing within the schedule completes its work. This use of system resources occurs because:
- An MSMQ implementation in an Orchestration workflow uses an asynchronous input/output (I/O) operation, which a worker thread from the NT thread pool performs.
- Worker threads in an NT thread pool do not exit if asynchronous I/O requests are pending. These threads wait until messages are received before the threads release the system resources that they hold. This rule is applied to running and dehydrated Orchestration schedules that contain a port or ports to message queuing.
RESOLUTION
To work around this problem, limit the number of BizTalk Orchestration workflows that contain MSMQ implementations, especially if you expect those workflows to be dehydrated.
STATUSMicrosoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article. MORE INFORMATION
BizTalk Orchestration ports to a Component Object Model (COM) component do not perform asynchronous I/O. Therefore, their worker threads exit and release the resources that the threads hold after a short wait.
| Modification Type: | Major | Last Reviewed: | 6/4/2003 |
|---|
| Keywords: | kbbug kbnofix KB312735 |
|---|
|