Signification de la propriété RetryExponential de ServiceBus

Question

J'ai du mal à comprendre la classe RetryExponential utilisée conjointement avec QueueClients (et je suppose également SubscriptionClients).

Les propriétés sont listées here, mais je ne pense pas que mon interprétation de leurs descriptions soit correcte.

Voici mon interprétation ...

var minBackoff = TimeSpan.FromMinutes(5); // wait 5 minutes for the first attempt? 
    var maxBackoff = TimeSpan.FromMinutes(15); // all attempts must be done within 15 mins? 
    var deltaBackoff = TimeSpan.FromSeconds(30); // the time between each attempt? 
    var terminationTimeBuffer = TimeSpan.FromSeconds(90); // the length of time each attempt is permitted to take? 
    var retryPolicy = new RetryExponential(minBackoff, maxBackoff, deltaBackoff, terminationTimeBuffer, 10); 

Mon rôle de travailleur a seulement tenté de traiter un message de la file d'attente deux fois dans la dernière heure, même si je pense que basé sur la configuration ci-dessus, il devrait partir plus souvent (toutes les 30 secondes + tout temps de traitement utilisé pendant la tentative précédente jusqu'à 90 secondes). Je suppose que ces paramètres forceraient une nouvelle tentative toutes les 2 minutes. Cependant, je ne vois pas comment cette interprétation est exponentielle du tout.

Est-ce que mes interprétations pour chaque propriété (dans les commentaires ci-dessus) sont correctes? Sinon (et je suppose qu'ils ne sont pas corrects), que signifient chacune des propriétés?

Answer 1

Comme vous vous en doutez, les valeurs que vous avez incluses n'ont aucun sens pour la signification de ces paramètres. Voici ma compréhension des paramètres:

• DeltaBackoff - l'intervalle à utiliser pour incrémenter de façon exponentielle l'intervalle entre les tentatives.
• MaximumBackoff - Le nombre maximum de fois que vous voulez entre deux tentatives. MaxRetryCount - la durée maximale pendant laquelle le système va réessayer l'opération.
• MinimalBackoff - le délai minimum requis entre les tentatives.
• TerminationTimeBuffer - la durée maximale pendant laquelle le système va réessayer l'opération avant d'abandonner.

Il sera toujours réessayer à la maxRetryCount, dans votre cas 10, sauf si la limite terminationTimeBuffer est d'abord atteinte.

Il n'essaiera pas non plus pendant une période supérieure à la valeur de terminationTimeBuffer, qui dans votre cas est de 90 secondes, même s'il n'a pas encore atteint le nombre maximal de tentatives. Le minBackoff correspond à la durée minimale d'attente entre les tentatives et maxBackoff correspond à la durée maximale d'attente entre les tentatives. La valeur DeltaBackOff est la valeur à laquelle chaque nouvelle tentative interne va croître exponentiellement. Notez que ce n'est pas une heure exacte. Il choisit aléatoirement un temps un peu moins ou un peu plus que ce temps, de sorte que plusieurs threads réessayant ne le font pas exactement au même moment. Son caractère aléatoire en découle un peu. Entre la première tentative réelle et la première tentative, il n'y aura que l'intervalle minBackOff. Puisque vous définissez votre deltaBackOff à 30 secondes, s'il l'a fait à une deuxième tentative, il serait d'environ 30 secondes plus le minBackOff. La troisième tentative serait de 90 secondes plus le minBackOff, et ainsi de suite pour chaque nouvelle tentative jusqu'à ce qu'elle atteigne la réduction maximale. Une chose que je tiens à souligner est que c'est une politique de réessayer, ce qui signifie que si une opération reçoit une exception, elle suivra cette politique pour la réessayer. Si des opérations telles que Retrieve, Deadletter, Différer, etc. échouent, alors cette politique de réessai est ce qui va démarrer. Ce sont des opérations contre le bus de service, pas des exceptions dans votre propre traitement.Je peux me tromper sur ce point, mais je crois comprendre que ceci n'est pas directement lié à la réception effective d'un message à traiter à moins que l'appel à recevoir échoue. Le traitement en continu est géré par la méthode Receive et votre propre boucle de code, ou par l'intermédiaire de l'action OnMessage (qui, dans les coulisses, utilise également le Receive). Tant qu'il n'y a pas d'erreur de tentative de réception, cette règle de nouvelle tentative n'est pas appliquée. L'intervalle utilisé entre les appels à recevoir est défini soit par votre propre utilisation de la méthode Receive qui prend un laps de temps, soit si vous définissez MessagingFactory.OperationTimeout avant de créer l'objet queueClient. Si un appel de réception atteint sa limite d'attente, soit parce que vous avez utilisé la surcharge qui fournit une période de temps sur Recevoir, soit sur la valeur par défaut, un Null est simplement renvoyé. Ceci n'est pas considéré comme une exception et donc la politique de réessai ne sera pas lancée.

Malheureusement, je pense que vous devez coder votre propre exponentielle pour le traitement réel. Il y a des tonnes d'exemples là-bas cependant.

Et oui, vous pouvez définir cette stratégie de nouvelle tentative sur QueueClient et SubscriptionClient.