问题标签 [azure-servicebus-topics]

我正在为 azure 开发两个 WebJobs：一个将使用一个主题将消息放入服务总线队列，另一个使用相同的主题订阅 ServiceBusTrigger。

消息已正确发送到服务总线队列，但在运行订阅了 ServiceBusTrigger 的 WebJob 时，这些消息不会以 FIFO 为基础进行处理。

将消息放入服务总线队列的 WebJob 的代码如下：

订阅服务总线触发器的 WebJob 具有以下代码：

如何实现将队列中的消息作为 FIFO 处理？

提前致谢！

有没有办法在不拉动或改变任何行为的情况下读取队列或主题中的消息（仅用于监视）？

我有一个在 azure web 作业中处理的主题和订阅，但是在一定数量的重试后，一些消息应该被移动到死信（队列或主题？）。我不知道处理死信消息需要什么。有人有代码示例吗？天蓝色的网络作业可以做到这一点吗？

我几乎放弃并使用重试计数器手动完成。目前，这就是我正在做的事情，但我不太喜欢将消息添加回同一个队列的想法：

背景

我在 Azure 服务总线中有一个主题 ( T1 )，它正在从客户端 (Web 应用程序) 获取数百万条消息。有 3 个订阅（S1、S2、S3）没有任何过滤器，它们由 3 个不同的后台进程（工作角色）创建。

问题

当工作角色运行时，只有第一个订阅（S1）似乎完全收到任何消息，然后休息（S2 和 S3）要么不接收任何消息，要么只得到其中的一小部分。所有订阅者都以相同的方式创建，具有相同的精确设置且没有过滤器。

服务总线资源管理器显示S1 的正确消息计数（~100K），但对于 S2 和 S3，活动消息计数非常低（小于 10，通常为 0）。在我看来，消息以某种方式被删除，甚至没有被客户接收。

调查问题的最佳方法是什么以及为什么订阅者之间的消息计数不匹配。关于什么可能是错的任何建议？

我有一个进程（进程 A）不断向 ASB 主题发送事件。该主题有多个消费者，因此有多个订阅。因此，可以说消费者的流程之一已关闭。由于这个原因，主题变得满了，因为消息没有被消费。这是否意味着进程 A 也会失败，因为它无法将消息完整发送到 ASB 主题？

我正在使用代码片段将消息发送到服务总线主题。

和实施是

错误：-

"ErrorCode,12005,Message,""发送通知时出错：操作未在分配的 00:01:00 超时内完成。分配给此操作的时间可能是较长超时的一部分。对于有关异常类型和正确异常处理的更多信息，Exception,""Microsoft.ServiceBus.Messaging.MessagingException：操作未在分配的 00:01:00 超时内完成。分配给此操作的时间可能是更长的超时时间。

有关异常类型和正确异常处理的更多信息

我们正面临服务总线的问题。

1. 我们有一个主题，有两个订阅。
2. 我们已经启用了重复检测，窗口为 1 分钟（先尝试 2 秒）。我们正在使用重复检测来避免在短时间内处理多个消息（以保持消息之间的间隔）
3. 我们正在使用消息调度（ScheduledEnqueueTimeUtc）重复消息以在 5 分钟后出现，具有相同的消息 ID（每次使用调度创建新消息，并且旧消息完成）
4. 工作流程如下（问题）：
   • 第一次发布消息（无调度）
   • 这条消息立即被消息泵消费，一条具有相同细节和 5 分钟计划时间的新消息被发送到主题（UTC），预计它会在 5 分钟后出现
   • 该消息未出现在订阅中
5. 调试的时候没有出现这个问题
6. 当我们以至少 30 秒的延迟（预定）发送第一条消息时，它工作正常
7. 如果我们在关闭重复检测的情况下重新创建主题和订阅，我们可以使用上述工作流程获取消息

由于我们不知道发布的消息发生了什么，因此我们需要帮助来确定问题的根本原因。

根据这篇文章：https ://azure.microsoft.com/en ...，服务总线每个队列/主题每秒最多可以处理 2000 条消息。本文：https ://azure.microsoft.com/en... 说“这意味着分区队列或主题的整体吞吐量不再受单个消息代理或消息存储的性能限制。” 如果我们创建一个分区队列/主题，我相信它会在内部创建 16 个分区。我的问题是：分区队列/主题的吞吐量是否线性上升到 16 x 2000 = 32,000（近似值）？还是保持 2000 msg/sec 的吞吐量。您能否指出分区队列/主题的任何吞吐量基准？我们目前正在分析一个需要非常高吞吐量主题的场景。关于这个问题的指导将非常有帮助。

此问题也已发布在 Azure 站点上，网址为：https ://azure.microsoft.com/en-us/documentation/articles/service-bus-performance-improvements/

基本上，在 Azure 服务总线中，我有一个主题和一个订阅。

如果消息在上午 11:00 之间到达主题，我的订阅者应该还没有处理它。但是，在下午 14:00，我希望我的订阅者能够处理它。

有没有办法使用主题过滤器本地实现这一点？

我在有关过滤器的官方文档中没有找到任何提及这种用例的内容。
事实上，所有展示的示例都是关于：
“订阅者处理这种消息，或者永远不会”。
我正在寻找：
“订阅者希望处理这种消息，但是稍后在特定时间”。

我正在设置主题/订阅服务，需要有关我的 SQLFilter 语法的帮助，以便我可以访问 BrokeredMessage 属性，特别是 To 属性。访问消息的系统属性的 SQL 过滤器的正确语法是什么？

我有一个使用本教程的工作示例，我可以根据需要发送和接收我的主题/订阅：https ://azure.microsoft.com/en-us/documentation/articles/service-bus-queues-topics-subscriptions/

但是，现在我想根据 BrokeredMessage 的 To 属性为每个订阅设置 SQL 过滤器。我遵循的教程提到可以“创建订阅时，您可以提供对消息属性进行操作的过滤器表达式，包括系统属性（例如，标签）和自定义应用程序属性（例如，StoreName .)”

如果我设置自定义属性，例如 StoreName，如下所示：

并使用如下 SQL 过滤器设置订阅：

订阅按预期过滤。但是，如果我尝试使用文章中描述的 BrokeredMessage 对象的 To 属性（或标签），我将无法使其工作。我尝试了以下 SQL 过滤器，但没有成功。访问消息的系统属性的正确语法是什么？