清理Azure服务总线上没有序列号的延迟消息
如果丢失了序列号，是否有办法恢复或删除Azure服务总线上的延迟消息？
场景是：我想使用BrokeredMessage。Defer（）来延迟消息。我计划记录序列号，并在以后使用它来检索消息。但是如果出了问题——假设部署了一些错误代码——并且序列号没有正确记录，那么这条消息似乎将以延迟状态保留在服务总线上，直到消息过期，这可能是永远的。
这主要是因为该消息将占用队列或订阅上的空间，除了完全删除队列/订阅之外，我还没有找到任何方法来恢复该空间。
有没有办法接收或删除“丢失”的延迟消息？
共有2个答案
至于防止由于序列号丢失而导致孤立的延迟消息，您应该在维护它们的存储过程中构建弹性，可能使用另一个队列。换句话说，延迟消息时，请在另一个队列或主题中创建消息，以存储延迟的序列号或整个消息（克隆）。
我通常将所有延迟的消息移动到我自己的“延迟主题”，并单独处理它们。换句话说，我自己的自定义延迟逻辑，完全避免了问题。如果自动超时逻辑在您的场景（BrokeredMessage.TimeToLive）中不起作用，这可能是一个更好的方法。
本文很好地部分解释了您的场景，使用了特殊的队列重载。接收：
http://markheath.net/post/defer-processing-azure-service-bus-message
由于您正在存储序列号（以弹性方式：-）），另一种选择是存储整个消息（JSON、属性包等）。），并在您想再次处理它时重新提交它（也许是从另一个队列）。
从队列或订阅中窥视消息也将返回延迟消息。延迟的消息将具有State=“Deferred”。
这样，您可以获得延迟消息的序列号，然后处理或删除这些消息。
您可以在ServiceBus Explorer中尝试此操作：
-
我正在使用Microsoft Azure ServiceBus对队列消息进行排队，并使用WCF对订阅进行排队。我正在尝试实现重试逻辑。我使用Peak/Lock查看消息，然后必须对消息进行一些本地处理。如果处理失败，我将解锁消息，以便再次尝试处理它。问题是我需要在处理尝试之间建立一个延迟。当前，它被弹出回队列，然后几乎立即被处理。两次尝试之间需要大约2分钟。
-
我试图使用服务总线队列作为IoT中心终结点将消息从IoT中心路由到函数应用。发送到IoT中心的消息在IoT中心中注册，但不会路由到服务总线队列。当我监视服务总线队列时，我只看到成功的请求。 我使用以下标准实现了两个路由规则： 和 我用Azure提供的示例测试了第二个，结果与之匹配。它们似乎都没有将消息转发到服务总线。 在下面找到一条示例消息，我正在尝试发送该消息。
-
我知道有一种方法可以确定Azure队列（商店帐户）中的邮件数量（或近似数量）；但是，有没有办法查询Azure服务总线队列上挂起的消息数？
-
我可以很好地从服务总线订阅接收消息，但当侦听器中发生异常时，似乎最终会将state=Modified和undeliverableHere=true的处置框架发送到服务总线。服务总线的文档说它不支持amqp修改的配置。 消息以服务总线中的延迟状态结束，我不知道如何将消息推回到活动状态。 JMS配置： 听众： 以下是我在日志中看到的内容： 消息传输开始 抛出异常，然后JMS在本地重新传递消息50次（为
-
我正在使用Azure服务总线队列。但是我不能使用“获取所有队列消息（peek Lock）：微软内置于api”从队列中获取所有消息。 有没有办法获取所有队列消息？ {"$连接"：{"值"：{"servicebus_1"：{"连接ID"："/订阅/c776fex3-6aec-4722-b099-b054c267b240/资源组/Plugin-Resources/提供者/Microsoft.网络/连接/
-
我有一个windows服务，它侦听Azure服务总线队列消息，以便从我的WebApi应用程序分发处理。此外，我还需要处理重复性任务（每晚/每周），我认为最好使用相同的系统来处理这些任务。 例如，假设我有一个“CleanupDb”队列，每天午夜删除过时的DB节点： 理论上这应该行得通，但我觉得我错过了一个更明显的处理方法。有没有更好的办法？