有害訊息處理Poison Message Handling

有害訊息是已超過應用程式傳遞嘗試次數上限的訊息。A poison message is a message that has exceeded the maximum number of delivery attempts to the application. 這種情形可能會在佇列架構的應用程式因為錯誤而無法處理訊息時發生。This situation can arise when a queue-based application cannot process a message because of errors. 為了符合可靠性的需求,佇列的應用程式會在交易中接收訊息。To meet reliability demands, a queued application receives messages under a transaction. 若中止了接收佇列訊息的異動,則會讓訊息留在佇列中,而訊息將會在新的異動中重試。Aborting the transaction in which a queued message was received leaves the message in the queue so that the message is retried under a new transaction. 如果造成異動中止的問題未予以更正,則接收的應用程式可能會卡在接收及中止相同訊息的迴圈中,直到超過傳遞嘗試次數的上限為止,因而形成有害訊息。If the problem that caused the transaction to abort is not corrected, the receiving application can get stuck in a loop receiving and aborting the same message until the maximum number of delivery attempts has been exceeded and a poison message results.

訊息變成有害訊息的原因有許多種。A message can become a poison message for many reasons. 最常見的原因是在應用程式中所發生的特定原因。The most common reasons are application specific. 例如,如果應用程式從佇列讀取訊息,並且執行某些資料庫處理,應用程式可能因為無法在該資料庫上取得鎖定,而造成中止交易。For example, if an application reads a message from a queue and performs some database processing, the application may fail to get a lock on the database, causing it to abort the transaction. 由於資料庫交易中止,訊息會留在佇列中,造成應用程式再次讀取該訊息,並重新嘗試取得資料庫鎖定。Because the database transaction was aborted, the message remains in the queue, which causes the application to reread the message a second time and make another attempt to acquire a lock on the database. 如果訊息包含無效的資訊,則也可能變成有害的。Messages can also become poison if they contain invalid information. 例如,採購單可能包含無效的客戶編號。For example, a purchase order may contain an invalid customer number. 在這些情況下,應用程式可能自動中止異動,而迫使訊息成為有害訊息。In these cases, the application may voluntarily abort the transaction and force the message to become a poison message.

在鮮少的情況下,訊息可能會無法分派至應用程式。On rare occasions, messages can fail to get dispatched to the application. Windows Communication Foundation (WCF) 層可能會發現訊息有問題, 例如, 訊息的框架錯誤、附加的訊息認證無效, 或是不正確動作標頭。The Windows Communication Foundation (WCF) layer may find a problem with the message, such as if the message has the wrong frame, invalid message credentials attached to it, or an invalid action header. 在這些情況中,應用程式絕不會接收該訊息,不過,訊息仍然可能會變成有害訊息,並且以手動方式處理。In these cases, the application never receives the message; however, the message can still become a poison message and be processed manually.

處理有害訊息Handling Poison Messages

在 WCF 中, 有害訊息處理提供一個機制, 讓接收的應用程式處理無法分派至應用程式的訊息, 或是分派至應用程式但因為應用程式特定而無法處理的訊息描述.In WCF, poison message handling provides a mechanism for a receiving application to deal with messages that cannot be dispatched to the application, or messages that are dispatched to the application but which fail to be processed because of application-specific reasons. 有害訊息處理是由每個可用佇列繫結中的以下屬性所設定:Poison message handling is configured by the following properties in each of the available queued bindings:

  • ReceiveRetryCount.ReceiveRetryCount. 整數值,表示從應用程式佇列傳遞至應用程式的訊息重試次數上限。An integer value that indicates the maximum number of times to retry delivery of a message from the application queue to the application. 預設值為 5。The default value is 5. 這個值對於立即重試即可修正問題的情況來說就已足夠,例如資料庫上發生暫時死結時。This is sufficient in cases where an immediate retry fixes the problem, such as with a temporary deadlock on a database.

  • MaxRetryCycles.MaxRetryCycles. 整數值,表示重試週期的上限。An integer value that indicates the maximum number of retry cycles. 重試週期包含從應用程式佇列將訊息傳輸至重試子佇列,然後在經過一段可設定的延遲之後,再從重試子佇列傳回應用程式佇列,重新嘗試傳遞。A retry cycle consists of transferring a message from the application queue to the retry subqueue and, after a configurable delay, from the retry subqueue back into the application queue to reattempt delivery. 預設值為 2。The default value is 2. Windows VistaWindows Vista 上,訊息最多會嘗試 (ReceiveRetryCount +1) * (MaxRetryCycles + 1) 次。On Windows VistaWindows Vista, the message is tried a maximum of (ReceiveRetryCount +1) * (MaxRetryCycles + 1) times. MaxRetryCyclesWindows Server 2003Windows Server 2003 上則會忽略 Windows XPWindows XPMaxRetryCycles is ignored on Windows Server 2003Windows Server 2003 and Windows XPWindows XP.

  • RetryCycleDelay.RetryCycleDelay. 重試週期之間的時間延遲。The time delay between retry cycles. 預設值為 30 分鐘。The default value is 30 minutes. MaxRetryCyclesRetryCycleDelay 會一起提供解決問題的機制,透過定期延遲之後的重試,進行問題的修正。MaxRetryCycles and RetryCycleDelay together provide a mechanism to address the problem where a retry after a periodic delay fixes the problem. 例如,這個機制會處理 SQL Server 中所設定等待異動認可的鎖定資料列。For example, this handles a locked row set in SQL Server pending transaction commit.

  • ReceiveErrorHandling.ReceiveErrorHandling. 列舉型別,指出要針對達到重試次數上限之後,而導致傳遞失敗的訊息所採取的動作。An enumeration that indicates the action to take for a message that has failed delivery after the maximum number of retries has been attempted. 這個值可以是 Fault、Drop、Reject 和 Move。The values can be Fault, Drop, Reject, and Move. 預設選項為 Fault。The default option is Fault.

  • Fault:Fault. 這個選項會將錯誤傳送至造成 ServiceHost 失敗的接聽項。This option sends a fault to the listener that caused the ServiceHost to fault. 訊息必須藉由某種外部機制從應用程式佇列中移除,應用程式才能繼續處理佇列中的訊息。The message must be removed from the application queue by some external mechanism before the application can continue to process messages from the queue.

  • Drop:Drop. 這個選項會捨棄有害訊息,而且該訊息永遠不會傳遞至應用程式。This option drops the poison message and the message is never delivered to the application. 如果訊息的 TimeToLive 屬性此時已過期,那麼訊息便可能會出現在傳送者寄不出的信件佇列中。If the message's TimeToLive property has expired at this point, then the message may appear in the sender's dead-letter queue. 如果未過期的話,訊息不會出現在任何位置。If not, the message does not appear anywhere. 這個選項表示,使用者尚未指定訊息遺失時的做法。This option indicates that the user has not specified what to do if the message is lost.

  • Reject:Reject. 這個選項只在 Windows VistaWindows Vista 上提供。This option is available only on Windows VistaWindows Vista. 這個選項會指示 Message Queuing (MSMQ) 將負值通知傳回傳送的佇列管理員,說明應用程式無法接收訊息。This instructs Message Queuing (MSMQ) to send a negative acknowledgement back to the sending queue manager that the application cannot receive the message. 訊息會放在傳送的佇列管理員寄不出的信件佇列中。The message is placed in the sending queue manager's dead-letter queue.

  • Move:Move. 這個選項只在 Windows VistaWindows Vista 上提供。This option is available only on Windows VistaWindows Vista. 這個選項會將有害訊息移到有害訊息佇列,以便之後讓有害訊息處理應用程式進行處理。This moves the poison message to a poison-message queue for later processing by a poison-message handling application. 有害訊息佇列是應用程式佇列的子佇列。The poison-message queue is a subqueue of the application queue. 有害訊息處理應用程式可以是從有害佇列讀取訊息的 WCF 服務。A poison-message handling application can be a WCF service that reads messages out of the poison queue. 有害佇列是應用程式佇列的子佇列, 可以定址為 net. msmq://< >/ applicationQueue;p oison, 其中電腦名稱稱是佇列所在電腦的名稱。位於, 而applicationQueue是應用程式特定佇列的名稱。The poison queue is a subqueue of the application queue and can be addressed as net.msmq://<machine-name>/applicationQueue;poison, where machine-name is the name of the computer on which the queue resides and the applicationQueue is the name of the application-specific queue.

以下為訊息的嘗試傳遞次數上限:The following are the maximum number of delivery attempts made for a message:

  • Windows VistaWindows Vista 上為 ((ReceiveRetryCount+1) * (MaxRetryCycles + 1))。((ReceiveRetryCount+1) * (MaxRetryCycles + 1)) on Windows VistaWindows Vista.

  • Windows Server 2003Windows Server 2003Windows XPWindows XP 上為 (ReceiveRetryCount + 1)。(ReceiveRetryCount + 1) on Windows Server 2003Windows Server 2003 and Windows XPWindows XP.

注意

成功傳遞的訊息不會有任何重試次數。No retries are made for a message that is delivered successfully.

為了持續追蹤嘗試讀取訊息的次數,Windows VistaWindows Vista 會保留一個計算中止計數之永久訊息屬性,以及另一個移動計數屬性,此屬性會計算訊息在應用程式佇列和子佇列之間移動的次數。To keep track of the number of times a message read is attempted, Windows VistaWindows Vista maintains a durable message property that counts the number of aborts and a move count property that counts the number of times the message moves between the application queue and subqueues. WCF 通道會使用這些來計算接收重試計數和重試迴圈計數。The WCF channel uses these to compute the receive retry count and the retry cycles count. Windows Server 2003Windows Server 2003Windows XPWindows XP上, 中止計數會由 WCF 通道保留在記憶體中, 如果應用程式失敗, 則會重設。On Windows Server 2003Windows Server 2003 and Windows XPWindows XP, the abort count is maintained in memory by the WCF channel and is reset if the application fails. 此外, WCF 通道可以隨時在記憶體中保留最多256個訊息的中止計數。Also, the WCF channel can hold the abort counts for up to 256 messages in memory at any time. 如果讀取第 257 個訊息,那麼最舊訊息的中止計數就會重設。If a 257th message is read, then the oldest message's abort count is reset.

中止計數和移動計數屬性可透過作業內容提供給服務作業。The abort count and move count properties are available to the service operation through the operation context. 以下程式碼範例將說明如何存取這兩個屬性。The following code example shows how to access them.

MsmqMessageProperty mqProp = OperationContext.Current.IncomingMessageProperties[MsmqMessageProperty.Name] as MsmqMessageProperty;
Console.WriteLine("Abort count: {0} ", mqProp.AbortCount);
Console.WriteLine("Move count: {0} ", mqProp.MoveCount);
// code to submit purchase order ...

WCF 提供兩個標準的佇列系結:WCF provides two standard queued bindings:

  • NetMsmqBinding.NetMsmqBinding. .NET Framework 系結, 適合用來與其他 WCF 端點執行以佇列為基礎的通訊。A .NET Framework binding suitable for performing queue-based communication with other WCF endpoints.

  • MsmqIntegrationBinding.MsmqIntegrationBinding. 此繫結適合用來與現有的訊息佇列應用程式進行通訊。A binding suitable for communicating with existing Message Queuing applications.

注意

您可以根據 WCF 服務的需求來改變這些系結中的屬性。You can alter properties in these bindings based on the requirements of your WCF service. 對於接收應用程式而言,整個有害訊息處理機制是在本機上進行的。The entire poison message handling mechanism is local to the receiving application. 傳送應用程式看不到這個程序,除非接收應用程式最後停止並且將負值通知傳回至傳送者。The process is invisible to the sending application unless the receiving application ultimately stops and sends a negative acknowledgment back to the sender. 在這種情況下,訊息會移到傳送者寄不出的信件佇列中。In that case, the message is moved to the sender's dead-letter queue.

最佳做法:處理 MsmqPoisonMessageExceptionBest Practice: Handling MsmqPoisonMessageException

當服務判定訊息是有害時,佇列的傳輸便會擲回 MsmqPoisonMessageException,其中包含有害訊息的 LookupIdWhen the service determines that a message is poison, the queued transport throws a MsmqPoisonMessageException that contains the LookupId of the poison message.

接收應用程式可實作 IErrorHandler 介面,以處理應用程式所需的任何錯誤。A receiving application can implement the IErrorHandler interface to handle any errors that the application requires. 如需詳細資訊, 請參閱擴充對錯誤處理和報告的控制For more information, see Extending Control Over Error Handling and Reporting.

應用程式可能需要以某種自動處理的方式將有害訊息移至有害訊息序列,讓服務能夠存取佇列中其餘的訊息。The application may require some kind of automated handling of poison messages that moves the poison messages to a poison message queue so that the service can access the rest of the messages in the queue. 唯一會使用錯誤處理常式機制接聽有害訊息例外狀況的情況,是在 ReceiveErrorHandling 設定設為 Fault 的時候。The only scenario for using the error-handler mechanism to listen for poison-message exceptions is when the ReceiveErrorHandling setting is set to Fault. Message Queuing 3.0 的有害訊息範例會示範這種行為。The poison-message sample for Message Queuing 3.0 demonstrates this behavior. 以下將說明處理有害訊息時所採取的步驟,包括最佳做法:The following outlines the steps to take to handle poison messages, including best practices:

  1. 請確認您的有害設定能反映您應用程式的需求。Ensure your poison settings reflect the requirements of your application. 處理設定時,務必確實了解 Windows VistaWindows VistaWindows Server 2003Windows Server 2003Windows XPWindows XP 上訊息佇列功能之間的差異。When working with the settings, ensure that you understand the differences between the capabilities of Message Queuing on Windows VistaWindows Vista, Windows Server 2003Windows Server 2003, and Windows XPWindows XP.

  2. 如有需要,請實作 IErrorHandler 來處理有害訊息錯誤。If required, implement the IErrorHandler to handle poison-message errors. 由於將 ReceiveErrorHandling 設為 Fault 時需要使用手動機制將有害訊息從佇列中移出,或更正外部相關的問題,因此通常的使用方式是在 IErrorHandler 設為 ReceiveErrorHandling 時實作 Fault,如下列程式碼中所示。Because setting ReceiveErrorHandling to Fault requires a manual mechanism to move the poison message out of the queue or to correct an external dependent issue, the typical usage is to implement IErrorHandler when ReceiveErrorHandling is set to Fault, as shown in the following code.

    class PoisonErrorHandler : IErrorHandler
    {
        public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
        {
            // No-op -We are not interested in this. This is only useful if you want to send back a fault on the wire…not applicable for queues [one-way].
        }
    
        public bool HandleError(Exception error)
        {
            if (error != null && error.GetType() == typeof(MsmqPoisonMessageException))
            {
                Console.WriteLine(" Poisoned message -message look up id = {0}", ((MsmqPoisonMessageException)error).MessageLookupId);
                return true;
            }
    
            return false;
        }
    }
    
  3. 建立服務行為可使用的 PoisonBehaviorAttributeCreate a PoisonBehaviorAttribute that the service behavior can use. 這個行為會在發送器上安裝 IErrorHandlerThe behavior installs the IErrorHandler on the dispatcher. 請參閱以下程式碼範例。See the following code example.

    public class PoisonErrorBehaviorAttribute : Attribute, IServiceBehavior
    {
        Type errorHandlerType;
    
        public PoisonErrorBehaviorAttribute(Type errorHandlerType)
        {
            this.errorHandlerType = errorHandlerType;
        }
    
        void IServiceBehavior.Validate(ServiceDescription description, ServiceHostBase serviceHostBase)
        {
        }
    
        void IServiceBehavior.AddBindingParameters(ServiceDescription description, ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, BindingParameterCollection parameters)
        {
        }
    
        void IServiceBehavior.ApplyDispatchBehavior(ServiceDescription description, ServiceHostBase serviceHostBase)
        {
            IErrorHandler errorHandler;
    
            try
            {
                errorHandler = (IErrorHandler)Activator.CreateInstance(errorHandlerType);
            }
            catch (MissingMethodException e)
            {
                throw new ArgumentException("The errorHandlerType specified in the PoisonErrorBehaviorAttribute constructor must have a public empty constructor", e);
            }
            catch (InvalidCastException e)
            {
                throw new ArgumentException("The errorHandlerType specified in the PoisonErrorBehaviorAttribute constructor must implement System.ServiceModel.Dispatcher.IErrorHandler", e);
            }
    
            foreach (ChannelDispatcherBase channelDispatcherBase in serviceHostBase.ChannelDispatchers)
            {
                ChannelDispatcher channelDispatcher = channelDispatcherBase as ChannelDispatcher;
                channelDispatcher.ErrorHandlers.Add(errorHandler);
            }
        }
    }
    
  4. 確認您的服務已標註為有害行為屬性。Ensure that your service is annotated with the poison behavior attribute.

此外,如果 ReceiveErrorHandling 設為 Fault,則 ServiceHost 會在遇到有害訊息時發生錯誤。In addition, if the ReceiveErrorHandling is set to Fault, the ServiceHost faults when encountering the poison message. 您可以連結到發生錯誤的事件並關閉服務、採取矯正措施,然後重新啟動。You can hook up to the faulted event and shut down the service, take corrective actions, and restart. 例如,可以標註傳播至 LookupIdMsmqPoisonMessageException 中的 IErrorHandler,當服務主機發生錯誤時,您就可以使用 System.Messaging API 接收來自佇列的訊息 (使用 LookupId 移除佇列中的訊息),以及將訊息保存在某些外部儲存區或另一個佇列中。For example, the LookupId in the MsmqPoisonMessageException propagated to the IErrorHandler can be noted and when the service host faults, you could use the System.Messaging API to receive the message from the queue using the LookupId to remove the message from the queue and store the message in some external store or another queue. 然後您可以重新啟動 ServiceHost 並繼續進行正常處理。You can then restart ServiceHost to resume normal processing. MSMQ 4.0 中的有害訊息處理示範此行為。The Poison Message Handling in MSMQ 4.0 demonstrates this behavior.

交易逾時及有害訊息Transaction Time-Out and Poison Messages

佇列傳輸通道和使用者程式碼之間可能會發生一種類別的錯誤。A class of errors can occur between the queued transport channel and the user code. 這些錯誤可能會在中間的各層中偵測到,例如訊息安全層或服務分派邏輯。These errors can be detected by layers in-between, such as the message security layer or the service dispatching logic. 例如,在 SOAP 安全層中偵測到遺失了 X.509 憑證,以及遺失的動作就是訊息會被分派至應用程式的情況。For example, a missing X.509 certificate detected in the SOAP security layer and a missing action are cases where the message does get dispatched to the application. 發生這類情況時,服務模型會捨棄訊息。When this happens, the service model drops the message. 由於訊息是在異動中讀取,而且不會提供異動的結果,因此異動最後會逾時、中止,而訊息則會放回佇列中。Because the message is read in a transaction and an outcome for that transaction cannot be provided, the transaction eventually times out, aborts, and the message is put back into the queue. 換言之,針對特定類別的錯誤,交易不會立即中止,而是會等待直到交易逾時。您可以使用 ServiceBehaviorAttribute 修改服務的交易逾時。In other words, for a certain class of errors, the transaction does not immediately abort but waits until the transaction times out. You can modify the transaction time-out for a service using ServiceBehaviorAttribute.

若要能在電腦上通用的原則下變更交易逾時,請修改 machine.config 檔案,並且設定適當的交易逾時。要注意的是,交易最後會根據所設定的逾時而中止,並回到佇列中,並且會遞增其中止計數。To change the transaction time-out on a computer-wide basis, modify the machine.config file and set the appropriate transaction time-out. It is important to note that, depending on the time-out set in the transaction, the transaction eventually aborts and goes back to the queue and its abort count is incremented. 最後,訊息會變成有害,並且根據使用者的設定進行正確的處置。Eventually, the message becomes poison and the right disposition is made according to the user settings.

工作階段及有害訊息Sessions and Poison Messages

工作階段如同單一訊息一樣,會進行相同的重試和有害訊息處理程序。A session undergoes the same retry and poison-message handling procedures as a single message. 先前所列出的有害訊息屬性會套用到整個工作階段。The properties previously listed for poison messages apply to the entire session. 這表示會重試整個工作階段,而且如果訊息遭拒絕,將移至最後的有害訊息佇列或傳送者寄不出的信件佇列。This means that the entire session is retried and goes to a final poison-message queue or the sender’s dead-letter queue if the message is rejected.

批次處理及有害訊息Batching and Poison Messages

如果訊息變成有害訊息,而且是批次的一部分,那麼整個批次都會復原,而通道會回到一次讀取一個訊息的狀態。If a message becomes a poison message and is part of a batch, then the entire batch is rolled back and the channel returns to reading one message at a time. 如需批次處理的詳細資訊, 請參閱批次處理交易中的訊息For more information about batching, see Batching Messages in a Transaction

有害佇列中之訊息的有害訊息處理Poison-message Handling for Messages in a Poison Queue

當訊息放入有害訊息佇列時,有害訊息處理就不會結束。Poison-message handling does not end when a message is placed in the poison-message queue. 有害訊息佇列中的訊息必須繼續讀取和處理。Messages in the poison-message queue must still be read and handled. 您可以在最終有害子佇列中讀取訊息時,使用有害訊息處理設定的子集。You can use a subset of the poison-message handling settings when reading messages from the final poison subqueue. 適當的設定為 ReceiveRetryCountReceiveErrorHandlingThe applicable settings are ReceiveRetryCount and ReceiveErrorHandling. 您可以將 ReceiveErrorHandling 設定為 Drop、Reject 或 Fault。You can set ReceiveErrorHandling to Drop, Reject, or Fault. 如果 MaxRetryCycles 設為 Move,則會忽略 ReceiveErrorHandling 並且擲回例外狀況。MaxRetryCycles is ignored and an exception is thrown if ReceiveErrorHandling is set to Move.

Windows Vista、Windows Server 2003 及 Windows XP 的差異Windows Vista, Windows Server 2003, and Windows XP Differences

如之前所述,並非所有有害訊息處理設定都適用於 Windows Server 2003Windows Server 2003Windows XPWindows XPAs noted earlier, not all poison-message handling settings apply to Windows Server 2003Windows Server 2003 and Windows XPWindows XP. 下列 Windows Server 2003Windows Server 2003Windows XPWindows XPWindows VistaWindows Vista 上之訊息佇列間的主要差異,都與有害訊息處理相關:The following key differences between Message Queuing on Windows Server 2003Windows Server 2003, Windows XPWindows XP, and Windows VistaWindows Vista are relevant to poison-message handling:

  • Windows VistaWindows Vista 中的訊息佇列支援子佇列,而 Windows Server 2003Windows Server 2003Windows XPWindows XP 則不支援子佇列。Message Queuing in Windows VistaWindows Vista supports subqueues, while Windows Server 2003Windows Server 2003 and Windows XPWindows XP do not support subqueues. 子佇列是在有害訊息處理中使用。Subqueues are used in poison-message handling. 重試佇列和有害佇列都是應用程式佇列的子佇列,應用程式佇列是根據有害訊息處理設定而建立的。The retry queues and the poison queue are subqueues to the application queue that is created based on the poison-message handling settings. MaxRetryCycles 會指示要建立多少重試子佇列。The MaxRetryCycles dictates how many retry subqueues to create. 因此,當在 Windows Server 2003Windows Server 2003Windows XPWindows XP 上執行時,會略過 MaxRetryCycles 並且不允許 ReceiveErrorHandling.MoveTherefore, when running on Windows Server 2003Windows Server 2003 or Windows XPWindows XP, MaxRetryCycles are ignored and ReceiveErrorHandling.Move is not allowed.

  • Windows VistaWindows Vista 中的訊息佇列支援負值通知,而 Windows Server 2003Windows Server 2003Windows XPWindows XP 則不支援。Message Queuing in Windows VistaWindows Vista supports negative acknowledgment, while Windows Server 2003Windows Server 2003 and Windows XPWindows XP do not. 來自接收佇列管理員的負認可會造成傳送佇列管理員將拒絕的訊息放在寄不出的信件佇列中。A negative acknowledgment from the receiving queue manager causes the sending queue manager to place the rejected message in the dead-letter queue. 因此,ReceiveErrorHandling.RejectWindows Server 2003Windows Server 2003 不可使用 Windows XPWindows XPAs such, ReceiveErrorHandling.Reject is not allowed with Windows Server 2003Windows Server 2003 and Windows XPWindows XP.

  • Windows VistaWindows Vista 中的訊息佇列支援能夠保留嘗試傳遞訊息之計數的訊息屬性Message Queuing in Windows VistaWindows Vista supports a message property that keeps count of the number of times message delivery is attempted. 這個中止計數屬性無法在 Windows Server 2003Windows Server 2003Windows XPWindows XP 上使用。This abort count property is not available on Windows Server 2003Windows Server 2003 and Windows XPWindows XP. WCF 會在記憶體中維護中止計數, 因此當伺服陣列中的多個 WCF 服務讀取相同的訊息時, 這個屬性可能不會包含正確的值。WCF maintains the abort count in memory, so it is possible that this property may not contain an accurate value when the same message is read by more than one WCF service in a farm.

另請參閱See also