当客户对象处置时,是否可以触发服务总线处理器?

发布于 2025-01-24 18:14:00 字数 148 浏览 0 评论 0原文

我正在调用ServiceBusClient.disposeasync用于处置客户端对象。但是,从该对象创建的一些处理器开始抛出一个例外,说该对象已被处置,并且无法再聆听。在调用处置时,有什么办法可以触发自动关闭服务处理器?或者,我应该掌握从该客户端创建的所有处理器,然后停止听力吗?

I am calling ServiceBusClient.DisposeAsync for disposing the client object. However, there are processors created from this object which starts throwing an exception saying the object is disposed and it cannot listen anymore. Is there any way to trigger auto closure of service processors when dispose is called? Or, should I get hold of all the processors created from this client and then stop the listening?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

甲如呢乙后呢 2025-01-31 18:14:00

简短的答案是否定的;处理器故意没有“停止处理”行为。您的应用程序负责调用stopProcessingasync

更多上下文:

servicebusclient拥有从中产生的所有子对象共享的连接。关闭/处置客户将有效地处置其子女。如果您在此时尝试调用服务操作,则会触发错误。

对于处理器,该应用程序负责致电开始和停止。由于处理器被设计为具有弹性,因此其目标是面对失败,继续恢复,并继续试图向前取得进步,直到召集停止为止。

虽然处理器确实知道一组已丢弃的网络资源是终端,但它无法理解您的意图。您的应用程序是否关闭了servicebusclient,目的是阻止关联的处理器?它是否在没有意识到还有处理器仍在运行的情况下关闭客户?

因为意图是模棱两可的,所以我们必须走更安全的道路。处理器将继续运行,因为它们会呈现给您的应用程序错误处理程序的例外 - 这确保了您的应用程序意识到存在问题,并允许您以最适合应用程序需求的方式做出响应。

另一方面,如果处理只是停止而您不打算这样做,那么您的应用程序很难检测和补救。您只会知道,处理器停止完成工作,很有可能没有进行大量调查就无法理解为什么。

The short answer is no; there is intentionally no "stop processing on dispose" behavior for the processor. Your application is responsible for calling StopProcessingAsync.

More context:

The ServiceBusClient owns the connection shared by all child objects spawned from it. Closing/disposing the client will effectively dispose its children. If you attempt to invoke a service operation at that point, an error is triggered.

In the case of a processor, the application holds responsibility for calling start and stop. Because the processor is designed to be resilient, its goal is to continue to recover in the face of failures and keep trying to make forward progress until stop is called.

While it's true that the processor does understand that a disposed set of network resources is terminal, it has no way to understand your intent. Did your application close the ServiceBusClient with the intent that it would stop the associated processors? Did it close the client without realizing that there were processors still running?

Because the intent is ambiguous, we have to take the safer path. The processors will continue to run because they'll surface the exceptions to your application's error handler - which ensures that your application is made aware that there is an issue and allows you to respond in the way best for your application's needs.

On the other hand, if processing just stopped and you did not intend for that to happen, it would be much harder for your application to detect and remediate. You would just know that the processor stopped doing its job and there's a good chance that you wouldn't be able to understand why without a good deal of investigation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文