问题标签 [azure-storage-queues]

我创建了一个在特定时间运行并将 JSON 消息插入存储队列的调度程序。JSON 消息是固定的，我在调度程序设置期间将其放在BODY字段中（显示为）。text/plain消息是：

在接收方（WebJob）上，我轮询队列，然后尝试反序列化这些消息中的 JSON。我得到的不是上面预期的 JSON，而是包装在 XML 消息中的 JSON 消息：

如何按原样发送 JSON 消息，即没有信封？

我使用 Azure 存储队列来处理我的项目处理流程。任务正在进入队列，由后台服务器处理并从队列中删除。

在某些情况下，某些任务的处理失败（由于环境变量 - 这是无法预料的）。在这种情况下，我想再次重试任务的执行。如果这次处理很好，一切都很好 - 只需将其从队列中删除即可。否则，将其从队列中删除并将一些消息写入日志。

所以，我正在寻找一些将元数据添加到 CloudQueueMessage 项的机制。我想到了一个名为“重试”的新元数据。这将是一个柜台。但我没有看到任何将元数据添加到队列项目的选项。

另一种选择是使用将添加“重试”属性的 Wrapper 类包装我的项目。从队列中取出项目后，使用修改后的“重试”值重新插入它。这应该可行，但不是一个优雅的解决方案。

你有什么建议？

I've been attempting this for a couple of weeks now. It's a pretty simple concept.

I just want to read messages off of an Azure cloud queue (Not a service buss!) from a local installation of BizTalk Server 2013 R2 and then allow BizTalk to do something with that message on our internal network. I am following this sort of example for creating a port to the Azure Queue:

http://social.technet.microsoft.com/wiki/contents/articles/20211.biztalk-server-2013-connect-to-window-azure-blob-storage.aspx

In my case, this needs to be a receive (it will be receiving queue messages). So, I have a receive location which is a WCF-WebHttp adapter pointed to: https://myappname.queue.core.windows.net/ with operations like:

That doesn't seem to magically do anything, and i'm not sure how I would initiate a read call to the Azure queue from BizTalk. Do I need to initiate a polling message of some sort? How would I do that with a WCF-WebHttp adapter port?

Maybe the question is: How do I make the orchestration which starts with a WCF-WebHttp receive location do something? Ie. how do I make it poll the queue / what should I be starting the orchestration with?

azure-storage为 node.js和,使用了两个不同的库，fast-azure-storage结果相同。

这就是我所做的：

1. 使用默认设置创建消息 - 好的。
2. 从队列中获取消息 - 好的。
3. 更新消息以重置visibility timeout- 好的。
4. 处理后删除消息 - 错误：MessageNotFound。

如果我跳过更新，一切都会顺利进行。

那么我做错了什么？

PS尝试分析http流量，似乎完全符合docs。就像这是 Azure 内部问题？也许有人有使用其他语言库更新消息的经验？curl由于 auth 标头的计算，对该服务太不方便了。

我喜欢更改在队列中消息到达时触发网络作业的情况下不可见 Q 消息的时间跨度。

我在调试时在开发阶段需要这个。有时由于错误，旧的 Q-msg 会重新出现，但我已经清理了消息所指的 blob-storage-item。因此 WebJob 崩溃是因为它试图获取不存在的 blob 对象。

如果我可以设置 Q 消息在 1 分钟后再次可见，那将很有帮助。

公共部分类函数 { public static void ProcessBulkFileQ( [QueueTrigger(AppConst.Q_BULKFILES)] JobInfo JobInfo, [Blob(AppConst.CONTAINER_BULKFILES + "/{BlobName}", FileAccess.Read)] 流 InputStream, [Blob(AppConst.CONTAINER_BULKFILES + "/{BlobName}")] CloudBlockBlob BlobToDelete ) {

我正在创建一个新的控制台应用程序，我将在 Azure 上将其作为 WebJob 运行。当我在 Visual Studio 中创建新应用程序时，它已经创建了一个包含以下方法的 Function.cs 类，该方法会自动从我的队列中提取消息并对其进行处理。

我的问题是如何更好地控制处理队列消息。例如，我想确保消息被处理和删除。这种方法似乎为我做了所有这些，但我怎么知道消息是否被正确处理？如果它失败了，我如何告诉它不要删除消息？

我有一个从 JavaScript 接收 XmlHttpRequests 的 WebApi2 控制器。

我每秒对 api 进行 +500 次调用，任何请求都会执行一些快速计算，然后我创建一个 Azure 存储队列（不是服务总线），传入一个序列化对象以供以后处理。直到这里一切正常，问题是 10-15% 的时间，仅初始化存储队列并添加 20k JSON 消息需要 500 毫秒到 2 秒之间的时间。我将请求分片到 10 个不同的队列中，但问题仍然存在，并且似乎与流量无关，基本上有时队列只是卡在创建过程中并变慢。

我已经禁用了 Nagle 和 Expect100Continue。

我想将这种架构转换为使用 EventHUbs，因为可能我的情况需要事件摄取器而不是简单的队列，需要最大速度。

但是EventHub的初始化有同样的问题！有时启动和接收一条消息需要 2 或 3 秒，平均为 400 毫秒。

我用秒表测量了速度。

这是我在 API 控制器中的代码：

InizializeEventHub 在哪里：

该服务使用云服务托管在 Azure 上，托管在 ServiceBus 和存储的同一位置 (WestUS)。

我的问题是：

• 1）初始化连接的这段时间是否正常？
• 2）Web Api 有没有办法为所有调用共享同一个 EventHubClient 实例？Redis 在 Lazy 类中使​​用 ConnectionMultiplexer 完成了类似的操作。
• 3) 我可以缓存 EventHubClient 对象吗？

对此问题的任何帮助将不胜感激，如果有某种方法可以加快初始化和 AddMessageAsync 操作，我什至可以返回存储队列。

谢谢

目前有没有办法通过“v2”存储帐户消息队列自动缩放 Azure 应用服务计划？当我尝试基于消息队列设置自动缩放时，它只显示我的“经典”存储帐户。正因为如此，我宁愿不破坏存储帐户并将其重新创建为经典帐户。

我的目标是将消息推送到 Azure 队列，并让 webjob 在给定时间处理它。例如 { message : "记住牛奶", time: 2016-02-10-10:10:00}

我可以通过将消息出列、检查时间戳并在时间未到时将其放回队列来天真地做到这一点。

在 Azure 世界中是否有更惯用的方式来做到这一点？

当 Webjobs 通过 QueueTrigger 从 Azure 存储上的队列中获取消息时，它会租用该消息（使其不可见）。如果（webjob）的触发功能需要很长时间来处理消息，这个租约是否会自动延长？或者我应该在函数中处理它？

在此链接Windows Azure Queues: Improvement Leases, Progress Tracking, and Scheduling of Future Work上，作者指出“消息的租约可以由执行原始出队的工作人员延长，以便它可以继续处理消息”

注意：我尝试了一个等待 20 分钟的网络作业（带有 QueueTrigger）。

它已成功完成。在此期间，没有其他 webjob 实例尝试尝试相同的队列项目（它没有变得可见）。因此，似乎存在租赁的自动续订机制。无论如何，我正在等待 Microsoft 员工或官方链接（msdn，azure，...）的答复。