BUG: BizTalk Framework 2.0 Documents Are Moved to Suspended Queue Before They Expire (307799)
The information in this article applies to:
- Microsoft BizTalk Server 2000
This article was previously published under Q307799 SYMPTOMS
When you configure a BizTalk Framework 2.0 document with a reliable envelope, and it does not receive an acknowledgement from the destination server before all retry attempts are used up, BizTalk Server moves the document to the Suspended queue after the last retry. This occurs although the document has not expired according to BizTalk Framework 2.0 specifications. If the receiving server sends a reliable acknowledgement back to the sending server after the original document has been placed in the Suspended queue, the receiving server does not log an error or delete the original document from the Suspended queue. By default, an acknowledgement that is received under these conditions is tracked in the BizTalk Tracking database.
Because the original document remains in the Suspended queue, it may appear that the original document was not successfully sent and subsequently acknowledged by the receiving server, which is not true in this scenario.
If you resend the document that is in the source server's Suspended queue to the destination server, the destination server automatically discards the resent document because it has already received a document with the same UUID value in the <prop:identity> tag. BizTalk Server does not log any information to the event log when it discards duplicate documents.
CAUSE
The expiration for a BizTalk Framework 2.0 document is determined with the following algorithm:
expiration time = total tries * retry interval * 2
The total number of tries is the number of configured retries + 1 for the initial try. For example, if you configure a Messaging Channel with 4 retries at a 2 minute interval, the document expiration time will be:
(4 + 1)tries * 2 minutes * 2 = 20 minutes
Because BizTalk Server moves the document from the Retry queue to the Suspended queue immediately after all retries have been used up, the document remains unexpired in the Suspended queue for the time that was initially spent trying to send the document.
The extra expiration time is built into BizTalk Messaging to allow time for a backup transport to process the document. If a BizTalk Server messaging port is configured to use a backup transport, BizTalk Server tries the primary transport by using the number of retries and interval specified in the channel. If they all fail, BizTalk Server tries the backup transport by using the number of retries and interval specified in the channel. If all attempts fail with both the primary and backup transports, the message is moved to the Suspended queue.
RESOLUTION
To prevent documents from being placed in the Suspended queue before they
expire, configure all messaging ports that use a reliable envelope to use a
backup transport. The backup transport that you specify can be exactly the same as the primary transport that is used on the messaging port.
Alternatively, you can hard code the ExpiresAT value for all Reliable messages by following the steps outlined in the following Knowledge Base article:
328211 INFO: Registry key to change the default ExpiresAT value for Reliable Messages
STATUSMicrosoft has confirmed that this is a problem in BizTalk Server 2000.
| Modification Type: | Major | Last Reviewed: | 11/5/2003 |
|---|
| Keywords: | kbbug kbnofix KB307799 |
|---|
|