Service Broker-Nachrichten nicht gesendet werden, wenn das Ziel

Question

Auf hohem Niveau neu gestartet, hier ist das, was passiert ist:

1. Wir haben zwei SQL Server 2008 R2 SP1-Systemen (Standard Edition unter Windows NT 6.1 (Build 7601: Service- Pack 1)) Sie summieren sich gut, kommunizieren bidirektional ohne Fehler oder Probleme.
2. Wir starten das System # 2 neu und erwarten, dass alle Service Broker-Nachrichten, die gesendet werden, während es nicht verfügbar ist, auf System Nr. 1 aufstehen, bis System Nr. 2 wieder verfügbar ist.
3. System # 2 kommt zurück und alles beginnt normal ohne Fehler.
4. Die Meldungen, die sich in System # 1 für System # 2 in der Warteschlange befanden, bleiben in der Warteschlange; Sie werden niemals gesendet. Darüber hinaus werden neue Nachrichten in dieser Konversation ebenfalls in Warteschlange gestellt und nie gesendet.
5. Nachrichten, die über neue Konversationen gesendet werden, werden problemlos übertragen.

Details zu den Nachrichten, die nie gesendet werden:

A. Während System # 2 nach unten, der transmission_status für die Nachrichten in den Warteschlange, die verschiedenen Fehler zeigen, dass es nicht mit dem System # 2 kommunizieren kann, wie erwartet.

B. Kurz nachdem das System # 2 wieder hochfährt, wird der transmissions_status für diese Nachrichten leer. Der leere Status ändert sich nie nach diesem Punkt.

C. Die Konversation, in der sich Nachrichten stapeln, befindet sich im Status CONVERSING/CO. Keine Spalten in der Systemansicht zeigen an, dass sich etwas von anderen Warteschlangen unterscheidet, die einwandfrei funktionieren. (Wenn ich Flags anders gesetzt finden könnte, würde ich die schlechte Konversation beenden, aber das System bietet keine Hinweise - abgesehen von der ständig wachsenden Warteschlangentiefe.)

D. Die Nachrichten werden niemals auf dem System empfangen # 2, in dem Sinne, dass meine Aktivierungsprozedur für diese Nachrichten nie aufgerufen wird.

E. In Profiler (mit allen Arten Broker Spur eingeschaltet), ein gutes Gespräch zeigt diese Dinge protokolliert:

Broker:Conversation CONVERSING 1 - SEND Message  Initiator          
Broker:Message Classify 2 - Remote Initiator 
[SQL Batch complete; SQL that caused the SEND to occur] 
Broker:Remote Message Acknowledgement 1 - Message with Acknowledgement Sent Initiator 
Broker:Message Classify  1 - Local Initiator 
Broker:Conversation CONVERSING 6 - Received Sequenced Message Target 
Broker:Remote Message Acknowledgement 3 - Message with Acknowledgement Received  Initiator 
Broker:Activation  Microsoft SQL Server Service Broker Activation 1 - Start 

eine Nachricht gesendet wird, die nur die erste stuck zeigt bekommen dazu bestimmt ist, zwei von diese Ereignisse:

Soweit ich sagen kann, ist dies umso weiter, dass diese Nachrichten erhalten. Es gibt keine Anzeichen dafür, dass SQL Server versucht, sie jemals wieder zu übertragen. System # 1 denkt, dass die Konversation immer noch gut ist, aber System # 2 hat es komplett vergessen. System # 1 scheint das nie herauszufinden. Wenn wir System # 1 anschließend neu starten, ist alles wieder normal und alle Nachrichten fließen wie beabsichtigt.

Ich habe berücksichtigt, dass diese Nachrichten tatsächlich gesendet wurden, aber dass die Bestätigung es nicht zurück zu System # 1 macht. Aber ich sehe keine Beweise für gesicherte Warteschlangen von Bestätigungen.

Wir haben für zahlreiche typische Probleme auf beiden Seiten geprüft:

Broker ist auf beiden Seiten aktiviert. 2. Alle Warteschlangen sind eingeschaltet, wobei alle geeigneten Dinge aktiviert sind (Enqueue, Receive). Warteschlangen werden nicht vergiftet. 3. Es existieren keine uns bekannten Berechtigungen. 4. Wir verwenden kein Feuer-und-vergessen. 5. Wir verwenden Gespräche wieder, wie es von verschiedenen Leuten empfohlen wird. (In der Tat, Konversation Wiederverwendung ist hier das Problem!) 6. Wir fangen SQL-Ausnahmen, Transaktionen wie angewiesen, etc. 7. ssbdiagnose gibt keine Fehler.

Wenn ein SQL Server-Host neu gestartet wird, erwarten wir, dass alle in der Warteschlange befindlichen Nachrichten gesendet werden, aber nicht. Was geht hier vor sich??

Answer 1

Ich verstehe, dass dies ein ziemlich alter Thread ist, aber ich habe genau die gleiche Situation zuvor bekämpft, und in meinem Fall war die Netzwerkkonfiguration der Schuldige.

Aus irgendeinem Grund hat der Initiator seine Nachrichten von einer IP-Adresse gesendet, aber eine andere IP wurde geöffnet, um eingehende Antworten zu akzeptieren (und diese zweite IP wurde in der Route des Ziels angegeben).

Ich habe dies durch Zufall, wirklich festgestellt. Als ich versuchte, Konversation auf der Zielseite zu beenden, es ist nicht geschlossen, aber die EndDialog Nachricht erschien in sys.transmission_queue mit dem Status:

Connection attempt failed with error: '10060(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)'.

Ich habe keine Ahnung, warum das Ziel Neustart den Zusammenbruch ausgelöst hat, aber wenn Netzwerktechniker haben das Problem behoben und ich habe die Route des Ziels geändert, alles ist wie von Anfang an an ihr Ziel geflogen.