Je suis un problème intermittent avec le bus de service Azure. Sporadiquement, placer un message sur le bus provoque l'exception suivante:
Type: InvalidOperationException P>
Message: L'opération ne peut pas être effectuée car le message de courtier '723AB13DAB34351A78BB687D0923B89' a déjà été consommé. Veuillez utiliser une nouvelle instance de courtierMessage pour l'opération. P>
StackTrace P>
RetryPolicy<ServiceBusTransientErrorDetectionStrategy>
4 Réponses :
L'erreur indique que le message a été "déjà envoyé", mais une erreur s'est produite dans le processus. Malheureusement, il n'y a pas de moyen facile de le savoir en inspectant le message et le message ne peut plus être réutilisé car il est considéré comme consommé. Nous travaillons sur certaines améliorations telles que vous permettant d'interroger l'état d'un tel message et de lancer une messagerie à la place d'une invalidation. Enfin, la possibilité de cloner un message aidera à faciliter la récupération de ces échecs.
Abhishek Lal - Puis-je supposer que le message sera livré ou devrais-je réessayer comme @Clemens dit ci-dessous avec de nouveaux courtiers? Remarque: Je dois éviter que le message soit livré deux fois merci à vous remercier
Si vous souhaitez garantir la livraison "exactement une fois", la désen-doublissement active la plainte sur la file d'attente (vous devrez fournir la propriété MessageID, mais nous ferons ensuite filtrer les doublons pour la fenêtre TIME spécifiée) msdn.microsoft.com/en-us/library/... et msdn.microsoft.com/en-us/library/ ...
La légende dit que même en 2021, Microsoft travaille toujours à la réparation de ce numéro ...
.... et pour empiler vers Abhishek's Réponse: Vous devez également construire une nouvelle courtierMessage pour chaque nouvelle tentative. Donc, votre périmètre de nouvelle réessation doit être un niveau supplémentaire supplémentaire. L'esprit que si vous mettez dans un flux, nous allons utiliser ce flux tel que dans le message de courtier et tirerez le coup droit sur le fil. Vous devrez donc faire des copies du flux à l'avance à l'avance pour une boucle de réessaye.
J'ai consulté un exemple de code partout, surtout sur le site windowsazure.com, et ils manquent extrêmement dans ce type de détail.
Argh .... Hit Entrez sur le commentaire .... ok, plus: Existe-t-il une exemple d'application qui traite de ce scénario, à l'aide des flux pour le corps du message et crée une réception fiable et le traitement des messages courtibles? J'ai trouvé une page du Wacat, mais il est daté de 2011 et possède des références d'API anciennes.
En particulier, si vous appelez Getbody
Est-il possible que le message ait pu être envoyé, même s'il y avait une erreur? Si le message est idempotent avant qu'une nouvelle tentative soit tentée dans ce cas?
Oui, il est possible qu'un message soit envoyé et qu'il existe une erreur sur le côté de l'accusé de réception des choses, la manière de garantir à la fois la livraison à la fois, une fois que la livraison sera de configurer la déplication de la file d'attente / de l'abonnement à l'aide de la propriété MessageId pour uniquement. Identifiez les messages et la valeur dupliquéShistorySyWindowow
Je l'ai récemment rencontré et j'ai récemment trouvé une autre cause: Si vous construisez une courtierMessage et définissez un point de pause avant de l'envoyer avec votre messagerie et inspectez les propriétés sur le message, il tentera d'accéder à la file d'attente et de lancer ceci. exception. Envoi simplement le message d'abord sans inspecter ses propriétés dans l'EDI ne causera pas ce problème.
C'était le cas pour moi!