Microsoft Knowledge Base Article
This article contents is Microsoft Copyrighted material.
©2005-©2007 Microsoft Corporation. All rights reserved.
Terms
of Use |
Trademarks
Article ID: 312735 - Last Review: June 4, 2003 - Revision: 2.2
BUG: Many Schedules with Ports to MSMQ Prevent Additional Schedules from Being Instantiated
This article was previously published under Q312735
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.
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.
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.
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
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.
APPLIES TO
- Microsoft BizTalk Server 2000 Standard Edition
- Microsoft BizTalk Server 2002 Standard Edition
Community Feedback System
Very often, it takes hours to solve a problem. Very often, you've looked high
and low, and have tried a lot of solutions. When you finally found it, chances
are, it was because someone else helped you. Here's your chance to give back.
Use our community feedback tool to let others know what worked for you and what
didn't.
Please also understand that the community feedback system is not warranted to be
correct, it's simply a system that we've built to let people try and help each
other. If something in a feedback response doesn't make sense to you, or you're
not comfortable making changes that the feedback talks about (like registry
edits), please consult a professional.
Thank you for using kbAlertz.com Feedback System.
-- Scott Cate