c# – azure服务总线没有收到所有消息(只有~65％)

同样的事情也发生在我身上.当我更改主题的名称时,它会再次运行一段时间.然后该服务总线主题再次损坏.只有65-71％的消息到达.没有帮助删除子命令,也没有删除主题.一段时间后,主题名称似乎以某种方式被污染了.这真的很糟糕,因为我没有办法告诉主题何时被破坏,除了系统不能像消息到达时那样工作.现在随机创建一个具有新名称的新主题似乎是一个非常糟糕的解决方案.

我在一个进程中通过循环测试它,发送消息,然后在另一个进程中循环,接收和计数.使用新的主题名称,它可以完美运行.我知道我只有一个订阅者,这是一个偷看锁,需要完成消息.

任何人？我怎么解决这个问题？

更新：
这里有一个问题.我创建了1个订阅并保持了与它的连接;创建了1个主题,并重新创建了10次总线,每次发送100 msg.没有消息丢失.
我创建了1个订阅,并且每次重新创建总线并发送100 msg时都会创建一个新的subscriptionclient.失去50％的消息.
似乎主题是知道以前的subscriptionclient并且msgs被发送到两个？

新问题：
我正试图解决如何处理这个问题.任何人都可以确认重新启动进程,导致创建具有相同订阅名称的新订阅客户端,这将使主题处理第一个和第二个订阅客户端之间的消息,即使第一个不再存在吗？
因为我试图通过重新启动我的订阅模块来处理错误,即通过检查主题是否存在的步骤,如果订阅存在,然后创建订阅客户端,我很难理解如何避免上述描述,以及避免将消息发送给不存在的用户..

建议解决方案,atm：
跟踪旧订阅,如果我必须重新启动进程,请创建新订阅？
在进程停止和创建新订阅之间留下一个窗口,其中消息将仅被抽出到“死”订阅.这些消息将丢失.
但至少在此之后的任何消息都将被新订阅接收.
男人..这个问题一定是以前处理过的.我做得不对.非常感谢这里的一些指导.

解：
这都是关于工作的正确工具.这种情况需要一个队列,而不是一个Pub / Sub.
一切都解决了.我正在进行与上面相同的测试,但是使用队列,当然,因为它决定了客户端收到消息,所以以前(死)订阅客户端从新消息中获取消息没有问题.一次只有一个队列客户端处于活动状态,因此只有那个可以从队列中取出消息的人.