这是我能找到的最近的问题：Azure Service Bus Subscription OnMessage not receiving messages。
同样的事情也发生在我身上。当我更改主题的名称时，它会再次运行一段时间。然后该服务总线主题再次损坏。只有65-71％的消息到达。没有帮助删除子命令，也没有删除主题。一段时间后，主题名称似乎以某种方式被污染了。这真的很糟糕，因为我没有办法告诉主题何时被破坏，除了系统不能像消息到达时那样工作。现在随机地随机创建一个新主题似乎是一个非常糟糕的解决方案。
我在一个进程中通过循环测试它，发送消息，然后在另一个进程中循环，接收和计数。使用新主题名称，它可以完美运行。我知道我只有一个订阅者，这是一个偷看锁，需要完成消息。
任何？我该如何解决这个问题？
更新 这里有一个问题。我创建了1个订阅并保持了与它的连接;创建了1个主题，并重新创建了10次总线，每次发送100 msg。没有消息丢失。 我创建了1个订阅，并且每次重新创建总线并发送100 msg时都会创建一个新的subscriptionclient。失去50％的消息。 好像主题知道以前的subscriptionclient并且msgs被发送到两个？
新问题： 我正在试图解决如何处理这个问题。任何人都可以确认重新启动进程，导致创建具有相同订阅名称的新订阅客户端，这将使主题处理第一个和第二个订阅客户端之间的消息，即使第一个不再存在吗？ 因为我试图通过重新启动我的订阅模块来处理错误，即通过检查主题是否存在的步骤，如果订阅存在，然后创建订阅客户端，我很难理解如何避免上述描述，以及避免将消息发送给不存在的用户..
对解决方案的建议，atm： 跟踪旧订阅，如果我必须重新启动进程，请创建新订阅？ 在进程停止和创建新订阅之间留下一个窗口，其中消息将仅被抽出到“死”订阅。这些消息将丢失。 但至少在此之后的任何消息都将被新订阅接收。 男人..这个问题一定是以前处理过的。我做得不对。非常感谢这里的一些指导。
解： 这都是关于工作的正确工具。这种情况需要一个队列，而不是一个Pub / Sub。 一切都解决了。我正在进行与上面相同的测试，但是使用队列，当然，因为它决定了客户端收到消息，所以以前（死）订阅客户端从新消息中获取消息没有问题。一次只有一个队列客户端处于活动状态，因此只有那个可以从队列中删除msgs的队列。
答案 0 :(得分：3)
解决方案：这都是适合工作的正确工具。这种情况需要一个队列，而不是一个Pub / Sub。一切都解决了。我正在进行与上面相同的测试，但是使用队列，当然，因为它决定了客户端收到消息，所以以前（死）订阅客户端从新消息中获取消息没有问题。一次只有一个队列客户端处于活动状态，因此只有那个可以将消息从队列中取出的人。