Azure ServiceBus TopicClient SendAsync实现在自己的包装器中



Azure ServiceBus TopicClient的SendAsync方法的正确实现是什么?

在第二个实现中,BrokeredMessage实际上会在SendAsync发生之前被释放吗?

public async Task SendAsync<TMessage>(TMessage message, IDictionary<string, object> properties = null)
{
using (var bm = MessagingHelper.CreateBrokeredMessage(message, properties))
{
await this._topicClient.Value.SendAsync(bm);
}
}

public Task SendAsync<TMessage>(TMessage message, IDictionary<string, object> properties = null)
{
using (var bm = MessagingHelper.CreateBrokeredMessage(message, properties))
{
return this._topicClient.Value.SendAsync(bm);
}
}

我想从等待/异步模式中获得更多。

回答您的问题:第二种方法可能会导致已处理对象出现问题,您必须等待SendAsync执行结束才能释放资源。

详细说明。

如果调用await,则方法的执行将在同一时刻停止,并且在不返回可重写的方法之前不会继续。代理消息将存储在本地隐藏变量中,不会被处理。

如果您不调用await,执行将继续,代理消息的所有资源将在实际消耗之前(因为using最后在对象上调用Dispose)或在消耗过程中释放。这必然会导致SendAsync内部出现异常。此时,SendAsync的执行实际上已开始

await所做的是"暂停"任何当前线程,并等待任务及其结果的完成。而这正是你真正需要的。async-await的目的是允许某些任务与其他任务同时执行,它提供了在真正需要时等待并发操作结果的能力,如果没有它,就不可能进一步执行

如果顶部的每个方法也是异步方法,那么第一种方法是好的。我的意思是,如果SendAsync的调用方是async Task,那么该调用方的调用方等等就是顶级调用方法。

此外,考虑可能引发的例外情况,此处列出了这些情况。正如您所看到的,存在所谓的瞬态错误。这是一种重试可能修复的错误。在您的代码中,没有这样的异常处理。重试模式的例子可以在这里找到,但提到的关于异常的文章可以提出更好的解决方案,这是另一个问题的主题。我还想添加一些日志系统,以至少了解任何非瞬态异常。

相关内容

最新更新