Azure Worker Rôle générant l'écriture d'une erreur inattendue dans le stockage du journal de trace

Question

Nous avons un rôle de travail s'exécutant dans le cloud qui interroge Azure CloudQueue en récupérant périodiquement les messages qu'un rôle Web a placés pour nous. Actuellement, le rôle de travail et le rôle Web sont hébergés dans la même application Cloud Service et nous n'exécutons actuellement qu'une seule instance. Pendant que nous testons, notre journalisation est activée et le contenu des messages ainsi que d'autres informations utiles apparaissent dans notre stockage en nuage que nous visualisons à l'aide de Cerebrata Azure Diagnostics Manager. (Excellent produit btw)

DiagnosticMonitorConfiguration diagConfig = DiagnosticMonitor.GetDefaultInitialConfiguration();

diagConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

Tout semble fonctionner remarquablement bien, mais parfois nous voyons un message détaillé dans le journal de suivi qui a simplement "Fail" comme message. Le code à partir duquel il semble être généré est enveloppé dans un catch try, il est donc étrange que nous ne voyions pas le message par ces moyens. Il semblerait que quelque chose se passe hors du contrôle de notre code, peut-être que le rôle de travail est en cours de redémarrage ou que le système de cloud op détecte une erreur majeure dont il ne peut s'occuper qu'en redémarrant son rôle de travailleur. Il récupère et continue, c'est donc un mystère pour nous ce qui pourrait arriver.

Ce que nous n'avons pas encore vérifié, c'est si nous perdons un message.

Toute aide serait grandement appréciée. Vive Kindo malais

Answer 1

sans la pile trace il est difficile de dire trop, mais avec l'enregistrement mis à verbose il est fort probable que vous voyez une exploitation forestière interne d'un des dll que vous utilisez. Par exemple, si vous exécutez une requête Azure Table qui provoque certains types d'erreurs, l'erreur sera déconnectée trois fois car la bibliothèque du client de stockage intercepte l'erreur, la trace et la réessaie.

Si l'erreur n'est pas détectée par votre bloc try catch, vous n'avez probablement rien à craindre. Si la délivrabilité des messages de file d'attente est importante pour vous, vous devez vous assurer que vous utilisez la surcharge de délai de visibilité de CloudQueue.GetMessage et ne supprimez le message que lorsque vous avez fini de le traiter. Vous pourriez finir par traiter deux fois certains messages, mais au moins vous les traiterez tous.

Answer 2

Si votre instance de rôle est redémarrée après un certain temps, c'est souvent parce que votre processus s'est arrêté en raison d'une exception non gérée.