Продажи: 1-800-867-1389

Управление жизненным циклом объекта обмена сообщениями

Обновлено: Март 2014 г.

Такие объекты обмена сообщениями, как TopicClient, QueueClient и SubscriptionClient, должны создаваться один раз и затем использоваться повторно, когда это возможно. Эти объекты соответствуют требованиям к потокобезопасности, что позволяет параллельно отправлять или получать сообщения из нескольких потоков. Существуют небольшие временные затраты, связанные с аутентификацией запроса клиента в Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS), которые имеют место при создании объекта обмена сообщениями. Поэтому рекомендуется помещать в кэш экземпляры объектовTopicClient, QueueClient и SubscriptionClient. Чтобы обеспечить оптимальное использование ресурсов, рекомендуется ограничить область кэша временем существования компонента обмена сообщениями, использующего соответствующие объекты обмена сообщениями Служебная шина.

Время существования объекта обмена сообщениями начинается, когда из объекта MessagingFactory извлекается новый экземпляр.

// The following actions are often performed upon initialization of an application-level messaging component.

string issuerName = "Issuer Name is retrieved from configuration file";
string issuerSecret = "Issuer Secret also comes from configuration file";
string serviceNamespace = "contoso-cloud";
string queuePath = "PurchaseOrders";

var credentials = TokenProvider.CreateSharedSecretTokenProvider(issuerName, issuerSecret);
var address = ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, String.Empty);
var messagingFactory = MessagingFactory.Create(address, credentials);
var queueClient = messagingFactory.CreateQueueClient(queuePath, ReceiveMode.ReceiveAndDelete);

Как было отмечено ранее, один объект QueueClient может быть повторно использован для отправки сообщений в заданную очередь или получения их из нее. Нет необходимости создавать новый экземпляр объекта QueueClient для каждого отправляемого или получаемого сообщения.

for (int i = 0; i < 5; i++)
{
    using (var msg = new BrokeredMessage(String.Format("Message #{0}", i)))
    {
        queueClient.Send(msg);
    }
}

Важно отметить, что объекты обмена сообщениями сохраняют активное подключение к инфраструктуре обмена сообщениями Служебная шина, размещенной на платформе Azure. Как и другие типы мультитенантных служб, службы обмена сообщениями через посредник, предоставляемые Служебная шина, квотируются, т. е. для них устанавливаются квоты на поддерживаемое количество одновременных активных подключений к одной сущности обмена сообщениями (например, очереди, разделу или подписке). Для сведения к минимуму количества одновременных подключений рекомендуется явным образом контролировать время существования объектов обмена сообщениями Служебная шина и закрывать их, если их повторное использование в дальнейшем не планируется. Также следует закрывать объект фабрики обмена сообщениями при нормальном завершении решения для обмена сообщениями.

noteПримечание
При закрытии объекта обмена сообщениями базовое подключение не закрывается, так как оно совместно используется несколькими объектами обмена сообщениями на уровне фабрики. В свою очередь, закрытие объекта фабрики обмена сообщениями приведет к закрытию базового подключения к инфраструктуре обмена сообщениями Служебная шина.

Чтобы закрыть определенный объект обмена сообщениями, необходимо вызвать его метод Close(), воспользовавшись одним из приведенных способов.

// When a queue client is no longer required, let's close it so that it doesn't consume a connection.

// Option #1: Closing a specific messaging object instance.
queueClient.Close();

// Option #2: Closing all messaging objects tracked by the messaging factory.
messagingFactory.Close();

Также следует обратить внимание, что в редких случаях объекты обмена сообщениями могут находиться в состояниях, не позволяющих нормальное закрытие. В таком случае необходимые действия будут выполнены посредством API обмена сообщениями через посредник, включая разрыв подключения, если его закрытие невозможно. Чтобы принять решение о вызове метода Abort() или Close(), не нужно выполнять проверку состояния. Это выполняется внутри API. Обратите внимание, что выполнение метода Close() без порождения исключения не гарантируется. Следовательно, если требуется обеспечить безопасное закрытие объекта обмена сообщениями, рекомендуется использовать дополнительный уровень защиты в виде конструкции try/catch.

noteПримечание
Хотя закрытие объекта обмена сообщениями не аналогично действию ликвидации, закрытый объект нельзя будет открыть повторно, если впоследствии вы решите снова использовать закрытый экземпляр. При попытке вызвать операцию с закрытым объектом обмена сообщениями возможно порождение понятного исключения, например: "Эта сущность обмена сообщениями уже закрыта, прервана или ликвидирована". Не существует открытого метода Open(), который можно вызвать из клиента, чтобы восстановить открытое состояние объекта обмена сообщениями. Необходимо создать новый экземпляр объекта обмена сообщениями. Данная рекомендация также относится к объектам MessagingFactory.

Время существования объекта обмена сообщениями завершается при вызове метода Close(). Самый простой способ обеспечить нормальное закрытие всех объектов обмена сообщениями, используемых в решении, это явное закрытие объекта MessagingFactory, который был использован для создания клиентов обмена сообщениями для очередей, разделов и подписок. Явное закрытие MessagingFactory неявно закрывает все объекты обмена сообщениями, которые созданы и принадлежат классу. Например, может потребоваться закрыть объект фабрики в методе Dispose() компонента обмена сообщениями, в методе OnStop(), предоставленном RoleEntryPoint, или из обработчика событий UnhandledException.

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft