VENDAS: 1-800-867-1389

Gerenciar o ciclo de vida do objeto do sistema de mensagens

Atualizado: março de 2014

Os objetos de mensagem, como TopicClient, QueueClient e SubscriptionClient, são destinados a serem criados e reutilizados sempre que possível. Estes objetos são compatíveis com a segurança de thread, permitindo o envio e recebimento de mensagens em paralelo a partir de threads múltiplos. Há algumas pequenas sobrecargas associadas à autenticação de uma solicitação cliente no Acess Control do Active Directory do Microsoft Azure (também conhecido como Access Control Service ou ACS) durante a criação de um objeto de mensagem, logo é recomendado fazer cache das instâncias de objetoTopicClient, QueueClient e SubscriptionClient. Para utilização ideal dos recursos, considere limitar o escopo do cache para o ciclo de vida do componente de mensagem que utiliza os objetos de mensagem do Service Bus respectivos.

A vida útil de um objeto de mensagem começa quando uma nova instância é recuperado a partir do objeto 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);

Conforme mencionado, um único objeto QueueClient pode ser reutilizado para envio ou recebimento de mensagem de ou para uma fila determinada. Não há necessidade de criar uma nova instância do objeto QueueClient para cada mensagem que esteja sendo enviada ou recebida:

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

É importante observar que os objetos de mensagem mantêm uma conexão ativa de volta na infraestrutura de mensagens do Service Bus hospedada na plataforma do Azure. Como em muitos outros tipos de serviços de vários locatários, os serviços de mensagem orientadas fornecidos pelo Service Bus estão sujeitos a cotas no que se refere a quantas conexões ativas simultâneas uma única entidade de mensagem (como uma fila, tópico ou assinatura) podem suportar. Para minimizar o número de conexões simultâneas, é aconselhável controlar explicitamente o ciclo de vida dos objetos de mensagem do Service Bus e fechá-los se não tiver intenção de reutilizá-los posteriormente. Também é recomendado fechar o objeto de mensagem de fábrica após uma conclusão normal de sua solução de mensagens.

noteObservação
Fechar um objeto de mensagem não fecha a conexão subjacente, já que múltiplos objetos de mensagem compartilham a conexão em um nível de fábrica. Por sua vez, fechar um objeto de mensagem de fábrica fechará a conexão subjacente com a infraestrutura de mensagens do Service Bus.

Para fechar um objeto de mensagem determinado, é necessário invocar seu método Close() usando uma das técnicas a seguir:

// 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();

Também é importante observar que em alguns casos raros, os objetos de mensagem podem terminar em um estado que evita que sua conclusão normal. Caso ocorra algo desse tipo, a API de mensagens orientadas garantirá que as ações adequadas sejam tomadas, incluindo abortar uma conexão se ele não puder ser concluído com êxito. Não é necessário executar uma verificação de status para decidir se haverá chamada de Abort() ou Close(). Isso é realizado internamente pela API. Observe que o método Close() não é garantia de conclusão sem que haja lançamento de uma exceção. Portanto, se desejar garantir que a conclusão de um objeto de mensagem esteja sempre segura, uma camada adicional de proteção no formato de uma construção try/catch é recomendada.

noteObservação
Apesar de a conclusão de um objeto de mensagem não ser igual a uma ação de descarte, um objeto concluído não pode ser reaberto se decidir reutilizar a instância concluída posteriormente. Caso tente invocar uma operação em um objeto de mensagem concluído, talvez você receba uma exceção autoexplicativa como "Esta entidade de mensagem já foi concluída, cancelada ou descartada." Não há método Open() público que possa ser chamado a partir do cliente para restaurar um objeto de mensagem para um estado aberto. É necessário criar uma nova instância do objeto de mensagem. Esta recomendação também se aplica aos objetos MessagingFactory.

A vida útil de um objeto de mensagem termina após chamar o método Close(). A maneira mais simples de garantir que todos os objetos de mensagem usados por uma solução sejam concluídos normalmente é ao concluir explicitamente o objeto MessagingFactory, usado para criar clientes de mensagem para filas, tópicos e assinaturas. Uma conclusão explícita no MessagingFactory implícito conclui todo os objetos de mensagem criados e pertencentes à classe. Por exemplo, você talvez deseje concluir o objeto de fábrica dentro do método Dispose() do seu componente de mensagens, dentro do método OnStop() fornecido por RoleEntryPoint ou a partir de dentro do manipulador de eventos UnhandledException.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft