PRB: BizTalk Messaging Queues List "No Processing Server" Status for Messages (320775)


The information in this article applies to:

  • Microsoft BizTalk Server 2000
  • Microsoft BizTalk Server 2002
This article was previously published under Q320775

SYMPTOMS

Documents are listed in the BizTalk Server Work queue or Retry queue with the following status:

No Processing Server

CAUSE

In a BizTalk Server Group, the Work queue, the Retry queue, and the Scheduled queue have a single thread dedicated to each queue for polling documents. Each thread picks one document at a time, and then sends the document to an in-memory queue that BizTalk Server reads items to, and from which worker threads dequeue. The documents are not removed from the queues until they are processed completely by BizTalk Server. These documents are listed as in process by the server name that processes each document. Any messages that are not currently being processed are listed in the BizTalk Server Work queue or Retry queue with the "No Processing Server" status.

STATUS

This behavior is by design.

MORE INFORMATION

When BizTalk Server processes a large number of documents, especially when you interface messaging with BizTalk Orchestration schedules, you may see documents from the Work queue and the Retry queue in the BizTalk Server Administrator tool. Typically, the name of the server that is processing the message appears in the processing server column for the message. Sometimes, the "No Processing Server" status is listed for a document as is described in the "Cause" section of this article.

BizTalk server uses queues as buffers to make sure that no data is lost when document traffic exceeds the capacity of the servers of a group to process documents. BizTalk Server document queues are maintained in a SQL Server database that is named the Shared queue database. All servers in a server group share a single Shared queue database. By default, the BizTalk Shared queue database is named InterchangeSQ.

The following queues make up the Shared queue database, and are graphically represented in the BizTalk Server Administrator. These queues are used to store incoming and outgoing documents that are in various stages of routing and processing in BizTalk Server.
  • Work Queue
    The BizTalk Server Work queue contains all documents that are currently being processed by any BizTalk Servers in your BizTalk Server Group. Documents arrive in this queue as a result of a submit() or submitsync() method call of the IInterchange interface. If documents appear to be "stuck" in the BizTalk Work queue it is possible that your BizTalk Server environment is experiencing performance problems. You can increase the throughput of your BizTalk Server Group by adding additional processing servers to your BizTalk Server Group, by separating your BizTalk Server processing and receiving Servers, or by performance tuning the individual BizTalk Servers in the group. For additional information about BizTalk Server Performance tuning, see the "Tuning the Performance of Your BizTalk Server Architecture" online Help topic in BizTalk Server 2002.
  • Scheduled Queue
    The Scheduled queue contains documents that have been processed by BizTalk Server, and are waiting to be transmitted based on the service window that was specified for the message port that the document passed through. The service window indicates a valid time range for transmitting documents.
  • Retry Queue
    The Retry queue contains documents that have failed transmission because of problems with the configured transport mechanism. For example, if a document passes through a Messaging port that is configured to use the HTTP transport, and the destination Web server is unresponsive, the document is placed into the BizTalk Server Retry queue to be retransmitted after the retry interval has expired. If you call a pooled schedule from BizTalk Messaging, and the destination schedule pool has already instantiated the maximum permitted number of schedule instances for the pool, the document that is being passed to the schedule is placed into the Retry queue.

    All documents that are placed in the Retry queue have associated values for the RetryInterval property and the RemainingRetryCount property. The values of these properties in each document are based on how these values are set for the channel that the document has passed through. BizTalk continues to retransmit each document in the Retry queue for the configured number of retries at the specified retry interval until the document is successfully transmitted, or until the configured number of retry attempts is used up. If the configured number of retry attempts for a document is used up, BizTalk places the document in the Suspended queue.
  • Suspended Queue
    The Suspended queue contains work items that did not process for a variety of reasons, including parsing errors, serialization errors, failed transmissions, or the inability to find a channel configuration.

REFERENCES

For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

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

Modification Type:MajorLast Reviewed:6/4/2003
Keywords:kbprb KB320775
©2002 Microsoft Corporation. All rights reserved.