我正在尝试在Azure中构建一个简单的WebAPI REST服务,后端有一个服务总线队列工作器。我可以从Web API向工作人员发送一条消息。然而,我试图发送更多的信息,只是为了看看一切是如何运作的。因此,我创建了一个简单的控制器,如下所示:
for (int i = 0; i < 100; i++)
{
var msg = new BrokeredMessage("Ping");
BioConnector.QueueConnector.OrdersQueueClient.Send(msg);
}
当我呼叫控制器时,我只收到工作人员接收到的大约1/2的消息。其余的似乎都被放弃了。
Azure服务总线提供持久的消息传递,因此您不会丢失任何消息。需要进一步调查的一些项目:1)是否有另一个工作人员角色实例正在从该队列中提取消息2)是否使用peek lock作为接收模式,因为这是保证至少一次传递的唯一方法。接收和删除模式不保证3)消息是否由于消息过期或超过最大传递计数而进入死信队列,也就是说,它们多次收到但未完成4)如果上述任何一项都不适用,则提出支持通知单,Azure产品团队可以调查这些症状,因为正如我提到的,这是一个持久的消息传递系统,因此不会“丢失”任何消息。
这是一个奇怪的问题。通过随机遍历“尝试事物”,我最终改变了队列的字符串名称,然后一切又开始工作了。除了队列的名称,我没有更改任何东西——根本没有更改任何配置参数。
Azure上的特定队列似乎有问题。
我在这里只写了一半关于测试的代码。我已经试过了
>
在应用程序中。配置,使用您自己提供的值将其更改为:
<appSettings>
<add key="Microsoft.ServiceBus.ConnectionString" value="Endpoint=sb://blahblah.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=pDk0b....=" />
</appSettings>
使用指令添加以下内容:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Xml;
using System.Xml.Linq;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;
using System.Configuration;
using System.Threading;
将代码方法更改为以下内容:
class Program
{
static void Main(string[] args)
{
string connectionString = ConfigurationSettings.AppSettings["Microsoft.ServiceBus.ConnectionString"];
var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);
QueueDescription queueDesc = new QueueDescription("TestQueue");
if (!namespaceManager.QueueExists(queueDesc.Path))
{
namespaceManager.CreateQueue(queueDesc);
}
QueueClient topicClient = QueueClient.CreateFromConnectionString(connectionString, queueDesc.Path);
int sentMsgCount = 0;
int recdMsgCount = 0;
for (int i = 0; i < 100; i++)
{
BrokeredMessage msg = new BrokeredMessage("Test message " + i);
topicClient.Send(msg);
sentMsgCount++;
Console.WriteLine("Sent Message: " + msg);
}
QueueClient subClient = QueueClient.CreateFromConnectionString(connectionString, queueDesc.Path);
bool moreMessages = true;
while (moreMessages)
{
BrokeredMessage recdMsg = subClient.Receive(TimeSpan.FromSeconds(3));
if (recdMsg != null)
{
Console.WriteLine("Received Message: " + recdMsg);
recdMsgCount++;
recdMsg.Complete();
}
else
{
moreMessages = false;
}
}
Console.WriteLine("# of sent msgs: " + sentMsgCount + ", # of rec'd msgs: " + recdMsgCount);
Console.Read();
}
}
> 在Azure Service Bus主题中,我有两个订阅subscription1和subscription2。我正在向主题发送一条消息。在subscription1中,消息被放弃,在subscription2中,消息被处理。subscription1中的已放弃消息是否将再次发送给两个订阅或仅发送给已放弃消息的订阅。 我也有点困惑,死信队列将是所有订阅都通用的,还是每个订阅都有一个单独的死信队
我在Azure中托管了两个云服务辅助角色,一个使用NServiceBus(Azure服务总线传输)消耗消息,另一个生成消息。 昨天,我部署了一个新版本的生产者工作者角色,而队列中仍然有大量消息,因为我们正在处理早上遗留下来的大量消息。当生产者启动时,它似乎已经清空(或者可能重新创建)队列,许多重要的生产消息丢失。这似乎很奇怪,但日志显示,大约在生产者角色启动时,消费者没有处理进一步的消息,我们知道
我正在尝试Azure服务总线队列。我有以下代码: 队列发送: 接收代码: 我看到,每当我打电话放弃时,信息都被写上了死信。我的假设是它应该被激活,并且可以被另一个客户接收。
我有一个服务总线主题,它有40万条消息从一个Azure函数推送到它。我有第二个Azure函数接收消息作为触发器。第2个函数运行时,成功处理了98%的消息。它给我留下了大约8000条失败的消息。由于异常或我的代码,消息被放弃了。我现在有8,000条消息坐在一个主题的订阅者中,我不能让函数重新尝试处理。 订阅服务器最初被设置为只允许1邮件传递。我之所以这么做,是因为在调试时,我看到同一条消息被多次处理
我在Azure Service Bus中使用代理消息传递(主题/订阅),我很好奇如何(或者是否)使用SSL保护通信。
我正在使用Python开发一个集成,从不同的Azure服务总线主题和队列中读取消息。但我在安排留言时有个问题。我无法查看计划的邮件。我想偷看它们,然后要么完成,要么让它们不读,直到预定的时间。我尝试查看队列和主题,但我找不到任何文档说明如何查看其中任何一个排定的消息。有人设法做到了吗?应该是一个非常常见的用例。在使用标准的REST调用时也没有发现任何问题。