MSMQ rejette les messages si la file d'attente de destination n'existe pas?

Question

J'ai rencontré une situation étrange:

Les messages sont envoyés de ServerA à ServerB. Il va dans la file d'attente sortante de ServerA et ensuite envoyé à la file d'attente de ServerB.

ServerB s'est écrasé. Nous avons dû reformater. Quand nous l'avons soulevé, nous avons oublié d'installer le service MSMQ.

Les messages commencent à se remplir dans la file d'attente sortante de ServerA jusqu'à ce que le programme qui envoie des messages lève une exception de ressources insuffisante.

Nous notons l'erreur et installé le service MSMQ sur ServerB. ServerA commence à vider immédiatement sa file d'attente sortante. Lorsque nous avons démarré le programme pour traiter les messages sur ServerB, il ne pouvait pas se connecter.

Nous avons appris que nous avions oublié de créer la file d'attente sur ServerB. Cependant, à ce moment-là, il était trop tard. Tous les messages 900K qui étaient placés dans la file d'attente de ServerA ont été envoyés à ServerB. D'après ce que je peux dire, ServerB les a jetés parce qu'il n'était pas configuré avec la file d'attente de destination. Je sais déjà que la solution correcte est d'arrêter la file d'attente sur ServerA jusqu'à ce que nous ayons complètement configuré ServerB.

La question est: Est-ce vraiment le vrai comportement que nous devrions attendre de MSMQ? J'aurais pensé qu'une approche de conception plus défensive aurait été pour ServerB de rejeter les messages au lieu de les prendre et de les jeter.

Answer 1

Lors de l'ouverture d'une file d'attente pour envoyer des messages à un ordinateur distant (lorsque dwAccess est défini sur MQ_SEND_ACCESS), Message Queuing ne vérifie pas l'existence de la file d'attente.

De Docs MSMQ:

http://msdn2.microsoft.com/en-us/library/ms699817.aspx

La raison semble être que MSMQ est destiné à être utilisé comme transport async si l'expéditeur envoie et beaucoup de choses différentes peuvent se produire le long de la façon de faire le message à ne pas être délivré. Il semble que la seule façon de vérifier avec certitude est de rechercher les messages d'accusé de réception négatifs qui reviennent. Nous n'avons jamais utilisé ceux-ci. Soit vous commencez à les utiliser, soit vous essayez de ne pas effectuer d'envoi à distance.

Usenet thread discussing this.

Answer 2

Cela dépend vraiment beaucoup du type de files d'attente que vous utilisez et des assurances que vous avez demandées à MSMQ de prendre avec les messages. Rappelez-vous que les messages dans MSMQ ont le temps de vivre des temps qui peuvent expirer pendant que le message est en transit (ou même des limites de temps à lire). En fonction de la façon dont vous configurez l'expéditeur, un message qui n'a pas pu être livré aurait pu être placé dans une file d'attente de rebut, donc je vérifierais certainement cela sur les deux serveurs pour voir ce qui s'y est passé.

Vous pouvez demander à MSMQ d'en faire beaucoup plus s'il s'agit d'un scénario que vous souhaitez mieux gérer. Par exemple, vous pouvez lui demander de conserver une copie des messages envoyés dans une file d'attente de journaux (puis l'évacuer si nécessaire). Ou vous pouvez lui demander des ACK positifs ou négatifs sur la livraison des messages ou même des messages à lire. Dans ces cas, les ACK/NACK sont envoyés à une file d'attente administrative de votre choix, à laquelle votre propre application peut surveiller et répondre.

Answer 3

Nous avons un comportement similaire dans lequel les messages dissappeared.Ce que j'ai remarqué est que si le 'UseDeadLetterQueue' est défini sur true, au moins lorsque la transmission échoue, il conserve une copie dans la file d'attente des lettres mortes sur le système source.

Exemple:

var message = new System.Messaging.Message(); 
message.UseDeadLetterQueue = true;