Nats.io comportement QueueSubscribe sur le délai d'attente

Question

J'évalue NATS pour la migration d'un logiciel MSG existant Je n'ai pas trouvé de documentation sur l'exception et la surcharge msg timeout. Par exemple:

• Après Abonné a été choisi , est-il au courant des paramètres de délai affichés par Publisher? Est-il possible de notifier une extension de temps supplémentaire?
• Si l'abonné élu est conscient que certains connexion SGBD est manquant et ne peut pas compléter Il pourrait être possible de rebondir le message

serveur NATS

sera prise un autre abonné et sera à nouveau après le même message?

Ciao Diego

Answer 1

Pour votre première question: Il me semble que vous essayez de publier un message de demande avec un délai d'attente (en utilisant le nc.Request). Si c'est le cas, le délai d'attente est géré par le client. En effet, le client publie le message de demande et crée un abonnement sur le sujet de la réponse. Si l'abonnement n'obtient aucun message dans le délai imparti, il vous informe de la condition de délai d'attente et se désinscrit de l'objet de la réponse.

Sur votre deuxième question - utilisez-vous un groupe de file d'attente? Un groupe de files d'attente dans NATS est un abonnement qui spécifie un nom de groupe de files d'attente. Tous les abonnements ayant le même nom de groupe de files d'attente sont traités spécialement par le serveur. Le serveur sélectionne l'un des abonnements aux groupes de files d'attente pour envoyer le message à une rotation entre eux à mesure que les messages arrivent. Cependant, la responsabilité du serveur est simplement de livrer le message. Pour faire ce que vous décrivez, implémentez votre fonctionnalité en utilisant request/reply en utilisant un timeout et un nombre maximum de messages égal à 1. Si aucune réponse n'est reçue après le timeout, votre client peut alors renvoyer le message de demande après un certain délai ou effectuer un autre type de logique de récupération. Le message de réponse devrait être votre «protocole» pour savoir que le message a été traité correctement. Notez que cela entre dans la conception de votre architecture de messagerie. Par exemple, il est possible que le délai d'expiration se déclenche une fois que le destinataire de la demande a reçu le message et l'a géré, mais avant que le client ou le serveur ne puisse publier la réponse. Dans ce cas, l'expéditeur de la demande ne serait pas en mesure de faire la différence et finirait par republier. Cela indique qu'un tel type d'interactions doit rendre les requêtes idempotentes pour éviter les effets secondaires en double.