Les messages Service Broker ne sont pas envoyés si la cible est redémarrée

Question

À un haut niveau, voici ce qui se passe:

1. Nous avons deux SQL Server 2008 R2 SP1 systèmes (Édition Standard sur Windows NT 6.1 (Build 7601: Service Pack 1)) Ils sont chantonner tout simplement beau, la communication bi-directionnelle avec pas d'erreurs ou de problèmes.
2. Nous redémarrage du système n ° 2, s'attendant à ce que tout Service de Courtier de messages envoyés, alors qu'il est indisponible seront en file d'attente sur le système n ° 1, jusqu'à ce que le système n ° 2 revient.
3. Système n ° 2 est de retour et tout ce qu'il démarre normalement sans erreur.
4. Les messages en file d'attente sur le système de n ° 1 pour le système n ° 2 restent en file d'attente; ils ne sont jamais envoyés. En outre, les nouveaux messages sur cette conversation aussi de la file d'attente et ne sont jamais envoyés.
5. Les Messages envoyés sur de nouvelles conversations sont transmises à l'amende juste.

Les détails sur les messages qui ne sont jamais envoyés:

A. Tout système de n ° 2 est en panne, le transmission_status pour les messages dans la file d'attente de montrer les différents messages d'erreur indiquant qu'il ne peut pas communiquer avec le système n ° 2, comme prévu.

B. Peu de temps après le système n ° 2 est de retour, la transmissions_status pour ces messages se vide. Le vide statut ne change jamais après ce point.

C. La conversation où les messages de la pile est dans la CONVERSATION/CO de l'état. Pas de colonnes dans la vue système indique rien en ce qui est tout différent des autres files d'attente qui fonctionnent très bien. (Si je pouvais trouver tous les indicateurs définis différemment, je voudrais savoir pour mettre fin à la mauvaise conversation, mais le système n'offre pas d'indices--autres que de la toujours croissante de la profondeur de file d'attente.)

D. Les messages ne sont jamais reçus sur le système n ° 2, dans le sens que mon activation de la procédure stockée n'est jamais appelée pour ces messages.

E. Dans le Profiler (avec tous les Broker types de trace activée), une bonne conversation montre ces choses étant connectés:

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

Un message envoyé qui est destiné à se coincer et ne montre que les deux premières de ces événements:

Broker:Conversation CONVERSING  1 - SEND Message    Initiator
Broker:Message Classify 2 - Remote  Initiator

Aussi loin que je peux dire, c'est d'autant plus ces messages. Il n'y a aucune indication que SQL Server essaie de les transmettre de nouveau. Système de n ° 1 pense que la conversation est toujours bonne, mais le Système n ° 2 a oublié complètement. Système de n ° 1 semble ne jamais le comprendre. Si nous avons ensuite redémarrer le système n ° 1, puis tout revient à la normale avec tous les messags qui coule comme prévu.

J'ai considéré que ces messages ont bien été envoyés, mais que l'accusé de réception est de ne pas en faire retour au système de n ° 1. Mais je ne vois aucune preuve de sauvegardé les files d'attente de remerciements.

Nous avons vérifié pour de nombreux problèmes typiques sur les deux côtés:

Le courtier est activé sur les deux côtés. 2. Toutes les files d'attente sont sur, avec toutes les choses activé (mise en file d'attente, recevoir). Les files d'attente ne sont pas empoisonnés. 3. Pas de problèmes d'autorisations d'exister que nous connaissons. 4. Nous ne sommes pas à l'aide de l'incendie et de l'oublier. 5. Nous sommes en réutilisant les conversations, comme plusieurs personnes vous recommandons de le faire. (En fait, la conversation ré-utilisation est le problème ici!) 6. Nous sommes le piégeage des exceptions SQL, l'utilisation de transactions selon les instructions, etc. 7. ssbdiagnose retourne pas d'erreurs.

Lorsqu'un hôte SQL Server est redémarré, nous nous attendons à ce que toute la file d'attente des messages finira par être envoyé, mais ils ne le sont pas. Ce qui se passe ici??

Answer 1

Je comprends que c'est un assez vieux thread, mais j'ai combattu exactement la même situation qu'avant, et dans mon cas, la configuration du réseau était le coupable.

Pour une raison quelconque, l'initiateur a envoyé ses messages à partir d'une adresse IP, mais un autre IP a été ouvert pour accepter les réponses entrantes (et cette deuxième propriété intellectuelle a été spécifiés dans la cible de la route).

J'ai détecté ce par accident, vraiment. Quand j'ai essayé de mettre fin à la conversation sur le côté cible, il n'a pas fermé, mais le message EndDialog est apparu en sys.transmission_queue le statut:

Tentative de connexion a échoué avec l'erreur: '10060(Une tentative de connexion a échoué car le parti connecté n'a pas répondu convenablement après une période de temps, ou une connexion établie a échoué car connectés l'hôte n'a pas pu répondre.)'.

Je n'ai aucune idée de pourquoi l'objectif de redémarrage a déclenché la rupture, mais lorsque le réseau des ingénieurs ont résolu le problème et j'ai changé la cible de la route, tout s'est envolé pour leurs destinations comme c'était prévu depuis le début.