当前位置: 首页 > 知识库问答 >
问题:

从Azure网站访问Azure服务总线队列

闾丘博超
2023-03-14

一旦部署到云,我无法从Azure网站访问Azure服务总线队列。在localhost上运行时,如果工作正常,我可以向队列发送消息,但如果我部署应用程序,在远程服务器上创建QueueClient时会出现异常:

“套接字连接被中止,因为对套接字的异步发送未在分配的超时00:00:59.4820817内完成。分配给此操作的时间可能是更长超时的一部分。”

我正在使用QueueClient。CreateFromConnectionString(连接字符串)方法。调试器显示连接字符串变量一切正常。

连接字符串为:

endpoint=sb://[已删除]。服务总线。窗户。净/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=[已删除]

我试图将“复制本地=真实”设置为所有引用,但没有成功。我正在使用WindowsAzure。ServiceBus 2.6.4 nuget.

此外,在NamespaceManager上也不会引发异常。QueueExists(名称),如果队列存在,但在NamespaceManager上引发异常。CreateQueue(名称),如果它不存在。

有人遇到过这样的问题吗?提前感谢任何提示。

更新1:

为了澄清,我提供了代码块和跟踪输出:

System.Diagnostics.Trace.TraceError("BEGIN");
var queueClient = QueueClient.CreateFromConnectionString(this.configuration.ServiceBusConnectionString, "points");
System.Diagnostics.Trace.TraceError(this.configuration.ServiceBusConnectionString);
queueClient.Send(new BrokeredMessage());   
System.Diagnostics.Trace.TraceError("END");

产生输出:

>

  • 连接到应用程序日志...

    2015-03-29T01:40:29欢迎,您现在连接到日志流服务。

    Application: 2015-03-29T01:40:41 PID[1952]错误BEGIN

    应用:2015-03-29T01:40:44 PID[1952]错误endpoint=sb://[发布前删除]。服务总线。窗户。净/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=[过帐前已删除]

    Application: 2015-03-29T01:41:48 PID[1952]错误套接字连接被中止,因为对套接字的异步发送没有在分配的超时00:00:59.5586593内完成。分配给此操作的时间可能是较长超时的一部分。

    更新2

    使用Azure存储API或SQL server时不存在连接问题。

    更新3

    网站实例和服务总线名称空间都是在北欧地区创建的。

  • 共有1个答案

    周楷
    2023-03-14

    我也无法让队列的连接字符串(在Azure UI中可用)工作,但是我发现当我使用PowerShell命令时

    Get-AzureSBNamespace -Name $servicebusNamespace
    

    为了获得连接字符串,它会产生一个完全不同的实际工作的连接字符串。因此,现在我使用以下代码预配所有服务总线队列:createServiceBusQueue.ps1

     类似资料:
    • 我正在使用azure服务总线主题和订阅机制,并希望处理所有在死信队列中的消息。 此外,我想通过C#中的Azure Web作业处理消息,并将其发送回队列。所以我想知道如何通过我的应用程序处理死信队列上的消息?

    • 我有一个服务总线Q,从Azure门户可以或多或少地看到服务总线Q包含多少条目。如何使用他们的管理API获取此计数?我仔细阅读了文档,但没有找到答案。

    • 今天晚上,我们观察到排队时间非常慢。我们的追踪数据告诉我们 需要45-60秒。这种情况发生在两个已经存在很长时间的队列上。他们几乎从来没有超过1-2条记录,我们使用一个带有服务总线触发器的网络作业来完成任务。我们正在排队等候一个简单的POCO。还有另一个队列正在快速排队,所以由于没有任何其他想法,我删除了两个麻烦的队列。当代码重新创建它们时(正如它被构建时所做的那样),它们在不到一秒钟的时间里开始

    • 在.NET core 2.0中使用创建时,我遇到了一个问题。 在体系结构中,当在用于创建用户的队列中创建新消息时,服务必须接收该消息并根据其中的信息在数据库中创建用户。 在Visual Studio2017中,我在下创建了一个新项目。 这种的正确实现是什么?在GitHub上有什么例子吗?提前道谢。

    • 使用WebJobs SDK时,将代理消息移动到死信队列的正确方法是什么?通常我会打电话给味精。死信()。但是,SDK负责管理代理消息的生命周期。它将调用msg。如果方法返回成功,则返回Complete(),如果发生异常,则将重试该消息。我需要第三种情况,告诉ServiceBus队列将消息移动到死信队列,因为它是一条坏消息。

    • 我有一个windows服务,它侦听Azure服务总线队列消息,以便从我的WebApi应用程序分发处理。此外,我还需要处理重复性任务(每晚/每周),我认为最好使用相同的系统来处理这些任务。 例如,假设我有一个“CleanupDb”队列,每天午夜删除过时的DB节点: 理论上这应该行得通,但我觉得我错过了一个更明显的处理方法。有没有更好的办法?