(0) exportieren Drucken
Alle erweitern

Verwalten des Lebenszyklus eines Messagingobjekts

Letzte Aktualisierung: März 2014

Für Messagingobjekte (z. B. TopicClient, QueueClient und SubscriptionClient) gilt Folgendes: sie werden ein Mal erstellt und nach Bedarf wiederverwendet. Diese Objekte sind mit Threadsicherheit kompatibel und ermöglichen Ihnen das parallele Senden oder Empfangen von Nachrichten von mehreren Threads. Für die Authentifizierung einer Clientanforderung in Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) fällt beim Erstellen eines Messagingobjekts ein kleiner Mehraufwand an. Daher wird empfohlen, TopicClient-, QueueClient- und SubscriptionClient-Objektinstanzen zwischenzuspeichern. Für optimale Ressourcennutzung sollten Sie den Cachebereich auf die Lebensdauer der Messagingkomponente einschränken, die die jeweiligen Servicebus-Messagingobjekte verwendet.

Die Lebensdauer eines Messagingobjekts beginnt, wenn eine neue Instanz aus dem MessagingFactory-Objekt abgerufen wird:

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

Wie bereits zuvor erwähnt, kann ein QueueClient-Objekt zum Senden oder Empfangen von Nachrichten an eine bestimmte oder aus einer bestimmten Warteschlange wiederverwendet werden. Es ist nicht erforderlich, eine neue Instanz des QueueClient-Objekts für jede Nachricht zu erstellen, die gesendet oder empfangen wird:

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

Beachten Sie unbedingt, dass die Messagingobjekte eine aktive Verbindung mit der Servicebus-Messaginginfrastruktur unterhalten, die auf der Azure-Plattform gehostet wird. Ebenso wie zahlreiche andere Typen von mehrinstanzfähigen Diensten unterliegen die von Servicebus bereitgestellten Brokermessagingdienste Kontingenten hinsichtlich der Anzahl der aktiven gleichzeitigen Verbindungen, die eine Messagingentität (z. B. eine Warteschlange, ein Thema oder ein Abonnement) unterstützen kann. Zum Minimieren der Anzahl gleichzeitiger Verbindungen wird empfohlen, die Lebensdauer der Servicebus-Messagingobjekte ausdrücklich zu steuern und sie zu schließen, wenn Sie nicht planen, diese zu einem späteren Zeitpunkt wiederzuverwenden. Außerdem sollten Sie auch das Messagingfactoryobjekt nach dem normalen Beenden Ihrer Messaginglösung schließen.

noteHinweis
Durch das Schließen eines Messagingobjekts wird die zugrunde liegende Verbindung nicht geschlossen, weil mehrere Messagingobjekte die Verbindung auf Factoryebene gemeinsam verwenden. Durch das Schließen eines Messagingfactoryobjekts wird jedoch die zugrunde liegende Verbindung mit der Servicebus-Messaginginfrastruktur geschlossen.

Wenn Sie ein bestimmtes Messagingobjekt schließen möchten, müssen Sie seine Methode Close() mithilfe einer der folgenden Techniken aufrufen:

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

Beachten Sie außerdem, dass in einigen seltenen Fällen die Messagingobjekte einen Zustand aufweisen können, der ein ordnungsgemäßes Schließen verhindert. Sollte eine solche Situation eintreten, stellt die Brokermessaging-API sicher, dass geeignete Aktionen ausgeführt werden, z. B. das Abbrechen einer Verbindung, wenn diese nicht erfolgreich geschlossen werden kann. Sie müssen keine Statusüberprüfung ausführen, um zu entscheiden, ob die Methoden Abort() oder Close() aufgerufen werden sollen. Dieser Vorgang wird intern durch die API übernommen. Beachten Sie bitte, dass für die Methode Close() nicht sichergestellt ist, dass diese ohne eine Ausnahme abgeschlossen wird. Wenn Sie also sicherstellen möchten, dass das Schließen eines Messagingobjekts immer sicher ist, wird daher eine zusätzliche Schutzschicht in der Form eines try/catch-Konstrukts empfohlen.

noteHinweis
Auch wenn das Schließen eines Messagingobjekts nicht mit einer Löschaktion identisch ist, kann ein geschlossenes Objekt nicht erneut geöffnet werden, wenn Sie sich später entscheiden, die geschlossene Instanz wiederzuverwenden. Wenn Sie versuchen, einen Vorgang für ein geschlossenes Messagingobjekt aufzurufen, erhalten Sie ggf. eine selbsterklärende Ausnahme, z. B. "Diese Messagingentität wurde bereits geschlossen, abgebrochen oder gelöscht". Es steht keine öffentliche Methode Open() zur Verfügung, die vom Client aus zum Wiederherstellen eines Messagingobjekts in einem geöffneten Zustand aufgerufen werden kann. Sie müssen eine neue Instanz des Messagingobjekts erstellen. Diese Empfehlung gilt auch für die MessagingFactory-Objekte.

Die Lebensdauer eines Messagingobjekts endet mit dem Aufruf der Methode Close(). Das einfachste Verfahren zum Sicherstellen, dass alle von einer Lösung verwendeten Messagingobjekte normal geschlossen werden, besteht im ausdrücklichen Schließen des MessagingFactory-Objekts, das zum Erstellen von Messagingclients für Warteschlangen, Themen und Abonnements verwendet wird. Ein ausdrücklicher Schließvorgang für MessagingFactory schließt implizit alle Messagingobjekte, die von der Klasse erstellt werden bzw. die sich in ihrem Besitz befinden. Sie möchten z. B. ggf. das Factoryobjekt in der Methode Dispose() Ihrer Messagingkomponente, in der Methode OnStop(), die von RoleEntryPoint bereitgestellt wird, oder aus dem Ereignishandler UnhandledException schließen.

Anzeigen:
© 2014 Microsoft