问题标签 [azure-servicebus-queues]

我一直在使用 azure 服务总线在 web 角色和工作角色之间来回发送消息，我真的认为这是一个非常好的解决方案，但最近我发现服务总线非常不稳定，有时它可以工作，有时消息会消失无缘无故变成一纸空文。我不知道它是否在我的代码中存在问题，但在我看来它只是不稳定的，因为有时它有效，有时它不起作用。所以我想知道是否有任何替代服务总线的解决方案，或者我很高兴知道在服务总线实现中出现的任何错误导致我的上述问题。下面是我的代码

在上面的代码中，我只展示了一个服务总线客户端的方法。在我的工作角色中，使用了 3 个服务总线客户端，即异步发送和接收来自不同队列的消息。它真的很奇怪，有些消息是如何工作的，有些消息是无缘无故地死信的，有时它是替代的，所以我认为我的代码中一定有问题，但我找不到任何问题。如果有人不知道问题是什么，请告诉我

我在使用 Azure 消息总线队列时遇到问题。

我已经MessageLockLostException抛出并且请求操作没有在分配的 00:01:10 超时内完成。分配给此操作的时间可能是较长超时的一部分。

我已将队列设置为ReceiveMode.PeekLock.

我也检查

为什么会发生这种情况，是什么导致锁失效？我从你收到的地方开始阅读，默认情况下你有 5 分钟。这个过程通常需要更长的时间。我想更新锁，但这不是很好。

使用 Java SDK (0.4.1) 从 SB 队列检索消息时，ReceiveQueueMessageResult即使相关队列为空，也会返回非空值。调用getValue()该结果返回一个非 null BrokeredMessage。我怎么知道我已经在一个空队列上调用了接收？显然，在分布式并发系统中查询大小不是一个选项。

我正在使用ReceiveAndDelete模式并且队列是新创建的，所以我知道它是空的。

根据文档，对 API 的底层调用应返回 204 的 StatusCode。我在返回的 Result 或 Message 中找不到访问该代码的任何方法。

在过去 26 小时左右，调用 ServiceBusConstract.getQueue(path) （其中 path 是一个不存在的队列）会引发 ServiceException，其最终原因是绑定问题。

引起：javax.xml.bind.UnmarshalException：意外元素（uri：“ http://www.w3.org/2005/Atom ”，本地：“feed”）。预期的元素是 <{ http://schemas.microsoft.com/netservices/2010/10/servicebus/connect }QueueDescription>,<{ http://schemas.microsoft.com/netservices/2010/10/servicebus/connect } SubscriptionDescription>,<{ http://schemas.microsoft.com/netservices/2010/10/servicebus/connect }TopicDescription>,<{ http://www.w3.org/2005/Atom }entry> at com.sun .xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent（UnmarshallingContext.java:647）

当同时使用 0.4.0 和 0.4.1 版本的 SDK 时，情况确实如此。

以前，此调用返回一个 GetQueueResult，其 .getValue() 方法返回 null。发现这一点，因为我的测试现在失败了。

生产服务是否已更新为不再与此调用兼容？ServiceBusContract.getQueue(nonExistentPath) 的预期行为是什么？

今天我体验到 azure queue 不起作用。是否可以重新启动它？

我知道有一种方法可以确定 Azure 队列（存储帐户）中的消息数量（或近似数量）；但是有没有办法查询 Azure服务总线队列上的待处理消息的数量？

我在尝试解析订阅 Azure 服务总线主题时收到的消息时收到序列化异常。有人看到我错过了什么吗？我将 Microsoft.ServiceBus.Samples.Messaging 用于 Silverlight 代码。

我有一个带有以下代码的网络服务：

我有一个带有以下代码的 SilverLightClient：

捕获到 SerializationException 反序列化 System.String 类型的对象时出错。根级别的数据无效。第 1 行，位置 1。

堆栈跟踪：

所以场景是我使用 SB 队列来限制对其他服务的传出回调。回调其他服务的标准问题之一是它们可能会在无法控制的时间内停机。假设我检测到目标已关闭/未响应，那么放弃该消息以使其不会立即重新出现在队列中的最佳模式是什么？

以下是我知道、尝试过或正在考虑的一些方法：

• 显然，如果我只是使用BrokeredMessage::Abandon()该消息将被解锁并放回队列中。对于这种情况以及我试图避免的情况，这显然是不可取的。

• 如果我只是忽略了我遇到错误并且从不调用 Abandon 的事实，这将阻止它立即出现，但我并没有真正细粒度地控制它再次出现之前的时间，我想实现一个衰减重试策略。

• 我想也许我可以调用BrokeredMessage::Abandon(IDictionary<string, object>)并以某种方式更新ScheduledEnqueueTimeUTC属性，但我已经尝试过了，除了最初发送消息之外，似乎没有办法影响该属性。有道理，但认为值得一试。

• 我考虑过仅BrokeredMessage::Complete()在这种情况下使用，实际上只是将带有属性集的消息的新副本排入队列。ScheduledEqueueTimeUTC

最后的子弹似乎太重了，但我得出的结论是，鉴于队列的固有性质，这可能是正确的答案。我只是想在我缺少的 Azure SB 队列中可能有更好的方法来执行此操作。

由于某种原因，托管在 Windows azure 上的队列不尊重.DefineEndpointName()配置。

Azure 总线上的队列名称始终以托管它的辅助角色命名。虽然这很好，但总的来说，如果可以选择手动覆盖约定，我会感觉好多了。

如何定义自己的队列名称？

我们使用 Azure 服务总线队列，并使用 AcceptMessageSession 接收消息（代码如下）。

接受 MessageSession 成功，但是当我在 MessageSession 上调用 Receive 时，返回 null。

这不会一直发生，而是在队列创建后的一段时间后发生。发生这种情况时，我验证队列不为空。当我关闭 MessageSession 时，我看到我的队列缩短了（消息数量正确！）但我没有收到我的消息......

我使用的代码：

更新：

我怀疑虽然某个会话的所有消息都已过期，但会话本身仍然存在，因此它被接受但没有收到任何消息。