Ist Azure TopicClient threadsafe?

Question

Ich habe mit einer Flut von Timeouts von TopicClient beschäftigt und ich denke, dass es mit Objekt Lebensdauer und Entsorgung in Verbindung stehen kann.

Ich verwende die TopicClient Klasse von Microsoft.ServiceBus.Messaging und Lesen dieser Best Practices Guide Staaten

Sie sollten nicht in der Nähe Messaging-Fabriken oder Warteschlange, Thema und Abonnement-Clients, nachdem Sie eine Nachricht senden, und dann neu erstellen wenn Sie die nächste Nachricht senden. Durch das Schließen einer Messaging-Factory wird die Verbindung zum Service-Bus-Service gelöscht, und beim Neuerstellen der Factory wird eine neue Verbindung hergestellt.

Das ist verwirrend für mich - dieses Dokument bezieht sich nicht speziell auf TopicClient, aber ich nehme an, es gilt. Vielleicht ist diese Annahme falsch?

Kann ich meinen TopicClient nur in einem statischen Member speichern, um die Verbindung nicht wiederherzustellen? Gibt es einen besseren Weg, damit umzugehen? Gibt es eine Art von Verbindungs-Pooling-Mechanismus, den ich stattdessen verwenden sollte?

Answer 1

Die documentation indicates, dass alle statischen und Instanzmitglieder des TopicClient threadsafe sind.

"Alle öffentlichen static (Shared in Visual Basic) Member dieses Typs sind Thread-sicher. Instance Mitglieder auch Thread-sicher sein sind garantiert."

las ich das Zitat Sie enthielten, dass es speziell auf das TopicClient nicht enthalten, weil es „Warteschlange, Thema und Abo-Kunden“, sagt. Ich habe das als QueueClient, TopicClient und SubscriptionClient gelesen.

Für Messaging-Subsysteme tendiere ich dazu, eine Gateway Pattern zu verwenden, die verwendet werden kann, um die Lebensdauer des Objekts zu handhaben, die für die Arbeit mit dem Messaging-Subsystem erforderlich ist. In Ihrem Fall würde das Gateway-Objekt die Lebensdauer des TopicClient oder MessageSender/Receivers behandeln.

Ich würde fragen, ob Sie die generischen Klassen MessageSender und MessageReceiver gesehen haben? Wenn diese generischen Objekte beim Senden verwendet werden, bedeutet dies, dass der Client-Code, der das Senden durchführt, nicht wissen muss, ob er an ein Thema oder eine Warteschlange sendet oder nicht.