问题标签 [brokeredmessage]

ServiceBus在没有任何自定义的情况下传递代理消息DataContractSerializer[as Default XML Serializer Take Place]。

注意： 主要是邮件正文是 HTML 电子邮件的类型。

但是当消息传递给工人角色之后deserialization，我看到一些随机文本附加在顶部正文中，

我试图给定制DataContractSerializer。但这搞砸了 HTML 符号。

我找到了一些格式化服务总线消息内容的文章，但仍然找到了摆脱模式字符串的方法。

按照现在我正在substring处理消息正文。

BrokeredMessage 上的文档说：

如果发送者在消息上设置的 TTL 超过了目的地的 TTL，那么消息的 TTL 将被后面的值覆盖。请参阅 DefaultMessageTimeToLive、DefaultMessageTimeToLive 和 DefaultMessageTimeToLive 以了解有关如何在实体级别控制消息 TTL 的更多信息。

因此，为了实现从我的“日志”订阅中自动删除消息，在创建订阅时，我将SubscriptionDescription.DefaultMessageTimeToLive属性设置为TimeSpan.FromDays(5).

当我创建并发送代理消息时，TimeToLive将该消息的属性保留为默认值，当我检查到达该订阅ExpiresAtUtc的消息时，消息的属性是31-12-9999 23:59. 并且TimetoLive属性是10675199.02:48:05.4775807。由于“目的地”订阅的 TTL 为 5 天，我预计会有一个值5.00:00:00。

我还需要做些什么才能使其正常工作吗？

使用 Service Bus Explorer 2.2.1.0 重现的步骤

1. 连接到 Azure 上的服务总线命名空间
2. 创建一个新主题“MyTopic”
3. 在主题下创建订阅“日志”并将默认消息时间设置为 5 天。
4. 右键单击 MyTopic 主题节点并选择“发送消息”
5. 在“向 MyTopic 发送消息”屏幕上：单击“开始”
6. 点击“日志”订阅节点
7. 单击“消息”按钮并选择Peek 10
8. 单击列表中的消息
9. 查看“消息属性”区域中的 TimeToLive 字段

我有一个 BrokeredMessageContext 类，它使用 Timer 定期检查和更新 BrokeredMessage 实例上的锁，以防处理此消息的进程运行时间超过预期。它通过调用 BrokeredMessage 实例上的 RenewLock() 方法来更新锁。

我希望这个调用会给我一个与原始锁具有相同超时的新锁（MSDN 声明“您可以在与实体锁超时相同的持续时间内更新锁，并且锁更新没有最大持续时间。”） ，但在调试时，似乎锁定超时增加了“任意”10-15 秒。我在 BrokeredMessage 实例上设置了一个监视，我可以看到每次调用 RenewLock() 时 LockedUntilUtc 属性都会增加 10-15 秒。

有谁知道为什么会这样？有什么办法可以延长锁的更新时间吗？

编辑：

下面迈克的回答是正确的。我发现我实际上是在尝试从一开始就每 10 秒更新一次锁，即使我的代码现在打算在锁到期前 20 秒之前更新锁。这一切都归结为时间比较问题以及我机器上的时间错误的事实（它提前了近一分钟）。哦！

尝试使用消息正文中的对象提交队列消息，但在以下行中收到 BrokeredMessage 异常

异常消息 -类型为“.Survey”，数据合同名称为“Survey: http://schemas.datacontract.org/2004/07/namespace ”。考虑使用 DataContractResolver 或将任何静态未知的类型添加到已知类型列表中 - 例如，通过使用 KnownTypeAttribute 属性或将它们添加到传递给 DataContractSerializer 的已知类型列表中。

这些是我拥有的模型 -

请帮助定位问题。

我目前正在对 Windows Server 的服务总线进行一些测试，并且我正在使用BrokeredMessage类的EnqueuedTimeUtc属性进行一些性能测试（计算有多少开销来自服务总线以及有多少来自我的应用程序代码）。

在主题和队列的配置中，我设置了自动转发以自动将消息从订阅转发到队列。

为了正确解释测量值，我必须知道BrokeredMessage上的EnqueuedTimeUtc是表示发送原始消息的时间，还是表示将消息转发到队列的时间。

它是哪一个？主题的原始入队时间，还是队列中的第二个入队时间？

我想确定如果队列中已经存在相同的消息，那么在webjob处理第一条消息时应该忽略第二条消息（不插入队列）。

我尝试了以下代码：

属性RequiresDuplicateDetection应确保重复消息。

但是webjob会为每个 messageId 触发。我给了睡眠时间 150000 毫秒，但在此之前我尝试将相同的消息插入到同一个队列中，由于重复的消息，不应插入该队列。

我尝试了MSDN，但它在 Azure Webjob 中不起作用。

网络作业代码：

我有一个单一订阅的简单主题。当我保持较小的消息大小（50kb 或更少即可）时，我可以一致地发送接收消息。

当我尝试发送大于 ~50kb 的消息时，消息发送成功，但从未收到。

消息不在死信队列中。我已经放弃了消息，经过几次重试后，它们从该子队列收到，但这些消息也不会出现在那里。

消息很简单：

创建一定大小的消息在这里：

最后，发送一个 64kb 的消息使其失败后，将不会收到以下所有消息。

发送和接收的代码非常“hello worldy”，但如果它有帮助，我可以发布更多。

这个问题听起来与我的问题非常相似，但没有答案。删除订阅似乎不是一个有效的解决方案。 从 Azure 主题接收消息产生 null，主题有未读消息

我正在使用 Microsoft 服务总线测试一个带有死信队列的项目。我发送了 26 条消息（代表字母表），并使用了一个程序，该程序在接收消息时将其中一些随机放入死信队列中。消息总是以偷看模式从死信队列中读取，所以一旦它们到达那里，它们就会呆在那里。运行几次后，所有 26 条消息都会在死信队列中，并且一直保留在那里。

然而，在阅读它们时，有时只阅读了几个（例如 6 个），有时是全部 26 个。

我使用命令：

有一个超时的 ReceiveBatch 过载，但这没有帮助，并且可能只会增加复杂性。

为什么不是每次都获取全部 26 条消息，因为它是在“peek”模式下使用的，并且消息一直在那里。

我可以使用“服务总线资源管理器”来实际验证所有消息是否都在死信队列中并保留在那里。

这主要是一个测试示例，但人们希望“ReceiveBatch”能够在确定性模式下工作，而不是以非常（糟糕）的随机方式工作......

I'm using adapter for Service Bus Queue. Therefore, I shouldn't use any class of Queue for return type. But I'm stucked on ReceiveAsync() method. How can I map Task<BrokeredMessage> to Task<MyAdapterClass> ?

Here is adapter Class for BrokeredMessage

And I want Method like this

On Driver project I want to use task like this:

我的要求是我必须将代理消息列表异步发送到 azure 服务总线。但是我无法正确实现SendBatchAsync方法。让我详细解释一下。这是我的代码：

SendMessageAsync 逻辑在哪里：

我的问题是，当我使用断点调试应用程序时，编译器会到达await topicClient.SendBatchAsync(brokeredMessageList);并退出代码，即应用程序调试已完成。它不会返回到 while 条件。但是，如果我使用SendBatch 而不是使用 SendBatchAsync ，它可以正常工作。我究竟做错了什么？

解决方案：问题出在调用上述函数的测试方法上。它是 void 类型。它应该是异步任务类型。非常感谢Ned Stoyanov在这方面帮助我。