Exportar (0) Imprimir
Expandir todo

Administración del ciclo de vida de objetos de mensajería

Actualizado: marzo de 2014

Los objetos de mensajería como TopicClient, QueueClient y SubscriptionClient están pensados para crearse una vez y reutilizarse siempre que sea posible. Estos objetos son conformes a la seguridad para subprocesos, lo que permite enviar o recibir mensajes en paralelo desde varios subprocesos. Hay una pequeña sobrecarga asociada a la autenticación de una solicitud de cliente en Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS) al crear un objeto de mensajería, por lo que se recomienda que copie en caché las instancias de objetoTopicClient, QueueClient y SubscriptionClient. Para un uso óptimo de los recursos, tenga en cuenta limitar el ámbito de la caché a la duración del componente de mensajería que usa los objetos de mensajería de Service Bus respectivos.

El ciclo de vida de un objeto de mensajería comienza cuando se recupera una nueva instancia del 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);

Como se ha mencionado anteriormente, un solo objeto QueueClient se puede reutilizar para enviar o recibir mensajes hacia o desde una cola determinada. No es necesario crear una nueva instancia del objeto QueueClient para cada mensaje que se envíe o se reciba:

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

Es importante tener en cuenta que los objetos de mensajería mantienen una conexión activa con la infraestructura de mensajería de Service Bus hospedada en la plataforma Azure. Como ocurre con muchos otros tipos de servicios multiempresa, los servicios de mensajería desacoplada que suministra Service Bus están sujetos a cuotas con respecto a la cantidad de conexiones simultáneas activas que puede admitir una sola entidad de mensajería (p. ej., una cola, un tema o una suscripción). Para minimizar el número de conexiones simultáneas, se aconseja controlar de manera explícita la duración de los objetos de mensajería de Service Bus y cerrarlos si no prevé reutilizarlos más adelante. También debería cerrar el objeto de fábrica de mensajería tras una terminación correcta de la solución de mensajería.

noteNota
El cierre de un objeto de mensajería no cierra la conexión subyacente, ya que varios objetos de mensajería comparten la conexión a nivel de fábrica. A su vez, el cierre de un objeto de fábrica de mensajería cerrará la conexión subyacente a la infraestructura de mensajería de Service Bus.

Para cerrar un objeto de mensajería determinado, debe invocar su método Close() mediante una de las siguientes técnicas:

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

También cabe destacar que en algunos casos excepcionales, los objetos de mensajería pueden terminar en un estado que evite que se cierren correctamente. En caso de que se produzca esa situación, la API de mensajería desacoplada garantizará que se lleven a cabo las acciones apropiadas, lo que incluye anular una conexión si no se puede cerrar correctamente. No tiene que realizar una comprobación de estado para decidir si llama a los métodos Abort() o Close(). La API se encarga de ello internamente. Tenga en cuenta que no se garantiza que el método Close() se complete sin producir una excepción. Por lo tanto, si quiere asegurarse de que el cierre de un objeto de mensajería sea siempre seguro, se recomienda un nivel adicional de protección en la forma de una construcción try/catch.

noteNota
Aunque el cierre de un objeto de mensajería no es igual a una acción de eliminación, un objeto cerrado no se puede volver a abrir si se decide reutilizar posteriormente la instancia cerrada. Si intenta invocar una operación respecto a un objeto de mensajería cerrado, es posible que reciba una excepción explicativa como "Esta entidad de mensajería ya se ha cerrado, anulado o eliminado". No hay ningún método Open() público al que se pueda llamar desde el cliente para restaurar un objeto de mensajería a un estado abierto. Debe crear una nueva instancia del objeto de mensajería. Esta recomendación también se aplica a los objetos MessagingFactory.

La duración de un objeto de mensajería termina después de llamar al método Close(). La manera más sencilla de asegurarse de que todos los objetos de mensajería que usa una solución terminan correctamente es cerrar explícitamente el objeto MessagingFactory usado para crear clientes de mensajería para colas, temas y suscripciones. El cierre explícito de MessagingFactory cierra de manera implícita todos los objetos de mensajería que crea y posee la clase. Por ejemplo, es posible que desee cerrar el objeto de fábrica dentro del método Dispose() de su componente de mensajería, dentro del método OnStop() proporcionado por RoleEntryPoint o desde dentro del controlador de eventos UnhandledException.

Mostrar:
© 2014 Microsoft