Обработка подозрительных сообщений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 that fail to be processed because of application-specific reasons. Настройте обработку подозрительных сообщений со следующими свойствами в каждой из доступных привязок в очереди:Configure poison message handling with 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 Vista, сообщение пытается выполнить максимум ( ReceiveRetryCount + 1) * ( MaxRetryCycles + 1) раз.On Windows Vista, the message is tried a maximum of (ReceiveRetryCount +1) * (MaxRetryCycles + 1) times. MaxRetryCycles не учитывается в Windows Server 2003 и Windows XP.MaxRetryCycles is ignored on Windows Server 2003 and Windows XP.

  • RetryCycleDelay.RetryCycleDelay. Промежуток времени между циклами повторных попыток.The time delay between retry cycles. Значение по умолчанию составляет 30 минут.The default value is 30 minutes. MaxRetryCycles и RetryCycleDelay вместе реализуют механизм устранения проблемы, решением которой может быть повторная попытка доставки сообщения с периодической задержкой.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 Vista.This option is available only on Windows Vista. Это указывает очереди сообщений (MSMQ) отправить отрицательное подтверждение обратно в Диспетчер очереди отправки, который приложение не может получить сообщение.This instructs Message Queuing (MSMQ) to send a negative acknowledgment 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 Vista.This option is available only on Windows 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:// <machine-name> / аппликатионкуеуе;p оисон, где Machine-Name — это имя компьютера, на котором находится очередь, а аппликатионкуеуе — имя очереди конкретного приложения.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:

  • ((ReceiveRetryCount + 1) * (MaxRetryCycles + 1)) в Windows Vista.((ReceiveRetryCount+1) * (MaxRetryCycles + 1)) on Windows Vista.

  • (ReceiveRetryCount + 1) в Windows Server 2003 и Windows XP.(ReceiveRetryCount + 1) on Windows Server 2003 and Windows XP.

Примечание

Для успешно доставленного сообщения повторных попыток доставки не выполняется.No retries are made for a message that is delivered successfully.

Чтобы отследить количество попыток чтения сообщения, в Windows Vista хранится устойчивое свойство сообщения, которое подсчитывает количество прерываний и свойство количества перемещений, которое подсчитывает количество передвижений сообщения между очередью приложения и подочередями.To keep track of the number of times a message read is attempted, Windows 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 2003 и Windows XP Счетчик прерываний сохраняется в памяти каналом WCF и сбрасывается в случае сбоя приложения.On Windows Server 2003 and Windows 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. Привязка, подходящая для взаимодействия с существующими приложениями MSMQ.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, содержащее LookupId подозрительного сообщения.When 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. Пример подозрительного сообщения для MSMQ 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 Vista, Windows Server 2003 и Windows XP.When working with the settings, ensure that you understand the differences between the capabilities of Message Queuing on Windows Vista, Windows Server 2003, and Windows XP.

  2. При необходимости реализуйте объект IErrorHandler для управления ошибками подозрительных сообщений.If necessary, 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. Создайте атрибут PoisonBehaviorAttribute, который сможет использовать поведение службы.Create a PoisonBehaviorAttribute that the service behavior can use. Поведение устанавливает IErrorHandler в диспетчере.The 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. Убедитесь, что служба помечена атрибутом PoisonBehaviorAttribute.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. Например, LookupId в исключении MsmqPoisonMessageException, распространенный на объект IErrorHandler, может запоминаться, и когда узел службы завершает работу с ошибкой, можно использовать API System.Messaging для получения сообщения из очереди с помощью 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. Например, отсутствие сертификата X.509, обнаруженное на уровне безопасности SOAP, и отсутствие действия - случаи отправки сообщения приложению.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. Применимые параметры: ReceiveRetryCount и ReceiveErrorHandling.The applicable settings are ReceiveRetryCount and ReceiveErrorHandling. ReceiveErrorHandling можно установить в значение Drop, Reject или Fault.You can set ReceiveErrorHandling to Drop, Reject, or Fault. MaxRetryCycles не обрабатывает исключение, если параметр ReceiveErrorHandling установлен в значение Move.MaxRetryCycles is ignored and an exception is thrown if ReceiveErrorHandling is set to Move.

Различия Windows Vista, Windows Server 2003 и Windows XPWindows Vista, Windows Server 2003, and Windows XP Differences

Как отмечалось ранее, не все параметры обработки подозрительных сообщений применяются к Windows Server 2003 и Windows XP.As noted earlier, not all poison-message handling settings apply to Windows Server 2003 and Windows XP. Следующие основные различия между очередью сообщений в Windows Server 2003, Windows XP и Windows Vista связаны с обработкой подозрительных сообщений:The following key differences between Message Queuing on Windows Server 2003, Windows XP, and Windows Vista are relevant to poison-message handling:

  • Очередь сообщений в Windows Vista поддерживает подочереди, в то время как Windows Server 2003 и Windows XP не поддерживают подочереди.Message Queuing in Windows Vista supports subqueues, while Windows Server 2003 and Windows 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 2003 или Windows XP MaxRetryCycles они игнорируются и ReceiveErrorHandling.Move не разрешаются.Therefore, when running on Windows Server 2003 or Windows XP, MaxRetryCycles are ignored and ReceiveErrorHandling.Move is not allowed.

  • Очередь сообщений в Windows Vista поддерживает негативное подтверждение, в то время как в Windows Server 2003 и Windows XP это не так.Message Queuing in Windows Vista supports negative acknowledgment, while Windows Server 2003 and Windows 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.RejectЭто не допускается в Windows Server 2003 и Windows XP.As such, ReceiveErrorHandling.Reject is not allowed with Windows Server 2003 and Windows XP.

  • Служба очереди сообщений в Windows Vista поддерживает свойство Message, которое хранит количество попыток доставки сообщений.Message Queuing in Windows Vista supports a message property that keeps count of the number of times message delivery is attempted. Это свойство счетчика прерываний недоступно в Windows Server 2003 и Windows XP.This abort count property is not available on Windows Server 2003 and Windows 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