0

我们有一个在云中运行的工作角色，它定期轮询 Azure CloudQueue，以检索 Web 角色为我们放置的消息。目前，worker 角色和 web 角色位于同一个云服务应用程序中，目前我们只运行一个实例。

在我们进行测试时，我们打开了日志记录，因此消息的内容和其他有用信息出现在我们使用 Cerebrata Azure 诊断管理器查看的云存储中。（顺便说一句，很棒的产品）

DiagnosticMonitorConfiguration diagConfig = DiagnosticMonitor.GetDefaultInitialConfiguration();

diagConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

实际上，这一切似乎都运行得非常好，但是有时我们会在跟踪日志中看到一条 Verbose 消息，其中仅包含“Fail”作为消息。它似乎是从中生成的代码被包装在一个 try catch 中，所以奇怪的是我们没有通过这些方式看到消息。

似乎发生了一些超出我们代码控制的事情，可能正在重新启动工作角色，或者云操作系统检测到只有它才能通过重新启动我们的工作角色来处理的重大错误。它会恢复并继续存在，因此对我们来说可能发生的事情有点神秘。

我们尚未确定的是我们是否正在丢失消息。

任何帮助将不胜感激。干杯 Kindo 马来语

4

2 回答 2

0

如果没有堆栈跟踪，很难说太多，但是由于日志记录设置为详细，您很可能会看到来自您正在使用的某个 dll 的一些内部日志记录。

例如，如果您运行导致某些类型错误的 Azure 表查询，则该错误将被注销 3 次，因为存储客户端库正在捕获错误、跟踪它然后重试。

如果您的 try catch 块没有捕获到错误，那么您可能无需担心。

如果队列消息的可传递性对您很重要，则应确保利用 CloudQueue.GetMessage 的可见性超时重载，并且仅在处理完消息后才删除该消息。您可能最终会处理两次消息，但至少您会处理所有消息。

于 2010-10-07T19:27:21.560 回答
0

如果您的角色实例在运行一段时间后重新启动，这通常是因为您的进程由于未处理的异常而退出。

于 2010-10-07T21:04:27.797 回答