【问题标题】:Azure Service Bus subscription.close() not working as intendedAzure 服务总线订阅。关闭()未按预期工作
【发布时间】:2020-11-11 04:50:23
【问题描述】:

我有一个横向扩展的应用程序,其中每个实例都连接到同名的 Azure 服务总线订阅。最终结果是只有一个实例可以对任何给定消息采取行动,因为它们都在监听同一个订阅。

有时,应用程序需要将实例置于空闲状态(服务结构 ActiveSecondary 副本)。发生这种情况时,我需要关闭订阅,以便该实例不再接收消息。如果最初有 2 个实例,一旦一个进入空闲状态,所有消息都应该发送到剩余的实例。这很重要,以便所有消息都由正确配置的主实例处理。

当实例空闲时,取消令牌被取消。我有代码监听取消并在最初创建订阅时生成的 SubscriptionClient 上调用 Close()。

问题是,即使我在一个实例上调用 Close(),消息仍然在它和主实例之间随机拆分。

我这样做的方式本身就是错误的,还是我的代码中的其他东西导致了这种行为?

【问题讨论】:

  • 你在处理OnChangeRoleAsync的变化吗?
  • 我在 canceltoken.Register 委托处理程序中处理它。根据服务结构生命周期文档,我假设任何活动的辅助节点要么被降级(因此令牌被取消),要么一开始就没有调用 runasync。这不正确吗?
  • 您能发布订阅/取消订阅代码吗?

标签: c# azure-service-fabric azureservicebus


【解决方案1】:

Azure 服务总线轨道 0 和 1 SDK 不支持 CancellationToken。如果您正在关闭您的客户端并且消息将不会被处理,那么当它们再次可见时,它们将被拾取另一个竞争实例。这就是MaxLockDurationMaxDeliveryCount 很重要的地方,以确保消息有足够的处理尝试来说明您所描述的情况而无需等待太长时间。

【讨论】:

    【解决方案2】:

    忽略此帖。结果我在一个实例中使用了两次相同的订阅名称,所以他们正在竞争这些事件。 close() 函数按预期工作。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2018-07-18
      • 1970-01-01
      • 1970-01-01
      • 2019-10-28
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多