NServiceBus - 在消息处理程序中使用 TransactionScopeOption.Suppress 时出现问题
我有一个端点，它有一个消息处理程序，可以执行一些 FTP 工作。 由于 ftp 过程可能需要一些时间，因此我使用 TransactionScopeOption.Suppress 将 ftp 方法封装在 TransactionScope 中，以防止事务超时异常。
这样做消除了超时异常，但是处理程序被触发了 5 次 （我的配置文件中的重试次数设置为 5）
文件可以通过 ftp 传输，但只被 ftp 传输了 5 次。
处理程序看起来像是在 10 或 11 分钟后重新启动。
一些测试代码如下所示：
public void Handle(FtpMessage msg)
{
using (TransactionScope t = new TransactionScope(TransactionScopeOption.Suppress))
{
FtpFile(msg);
}
}
任何帮助将不胜感激。
谢谢。
I have an endpoint that has a message handler which does some FTP work.
Since the ftp process can take some time, I encapsulated the ftp method within a TransactionScope with TransactionScopeOption.Suppress to prevent the transaction timeout exceptions.
Doing this got rid of the timeout exceptions, however the handler was fired 5 times
(retries is set to 5 in my config file)
The files were ftp'd ok, but they were just ftp'd 5 times.
the handler look like it is re-fired after 10 or 11 minutes.
some test code looks as follows:
public void Handle(FtpMessage msg)
{
using (TransactionScope t = new TransactionScope(TransactionScopeOption.Suppress))
{
FtpFile(msg);
}
}
Any help would be greatly appreciated.
thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的猜测是，如果不完成内部作用域，则会导致 NSB 创建的外部作用域回滚。这将导致 NSB 重试您的 FtpMessage。
尝试添加：t.Complete();调用 FtpFile 后，看看这是否适合您。
编辑：重读您的问题后，我意识到这无法解决您的超时问题。您是否尝试过增加超时时间？ （10 分钟是 machine.config 中的默认 maxValue，因此如果不修改 machine.config，则无法将其设置为更高）
My guess is that by not completing the inner scope you're causing the outer scope, created by NSB, to rollback. This will cause NSB to retry your FtpMessage.
Try to add: t.Complete(); after your call to FtpFile and see if that does it for you.
Edit: After rereading your question I realized that this won't solve your timeout issue. Have you tried to increase the timeout? (10 min is the default maxValue in machine.config so you can't set it to higher without modifying machine.config)
我建议将该端点配置为非事务性的，而不是试图抑制事务。如果是自托管，可以通过在初始化代码中包含 .IsTransactional(false) 来实现这一点，或者在使用通用主机时通过实现 IConfigureThisEndpoint、AsA_Client 来实现这一点。
I'd recommend configuring that endpoint as non-transactional rather than trying to suppress the transaction. Do that by including .IsTransactional(false) in your initialization code if self-hosting or by implementing IConfigureThisEndpoint, AsA_Client when using the generic host.
如果这确实是无法在事务超时内完成的 FTP 通信，另一种方法是将其转换为 Saga。
Saga 将由 FtpMessage 启动，在处理程序中，它将异步启动 FTP 工作，无论是在另一个线程中，还是通过另一个进程，或者其他方式，并在 saga 数据中存储足够的信息，以便稍后能够查找进度。
然后它会向 TimeoutManager 请求超时，无论超时时间有多长。收到超时后，它将在 saga 数据中查找状态，并检查正在进行的 FTP 工作。如果完成，则将传奇标记为完成，如果没有，则请求另一个超时。
或者，您可以有一个封装 FTP 通信的进程，该进程托管自己的总线，但没有任何自己的消息处理程序。它可以通过命令行（包括请求端点）接收其 FTP 信息，完成其工作，然后将消息发送回请求端点，表明其已完成。那么您就不必等待超时来继续该过程。
If this truly is an FTP communication that cannot be completed within the transaction timeout, another approach would be to turn this into a Saga.
The Saga would be started by FtpMessage, and in the handler it would start the FTP work asynchronously, whether in another thread, or via another process, or whatever, and store enough information in saga data to be able to look up the progress later.
Then it would request a timeout from the TimeoutManager for however long makes sense. Upon receiving that timeout, it would look up the state in saga data, and check on the FTP work in progress. If it's completed, mark the saga as complete, if not, request another timeout.
Alternatively, you could have a process wrapping the FTP communication that hosts its own Bus but does not have any message handlers of its own. It could receive its FTP information via the command line (including requesting endpoint), do its work, and then send a message back to the requesting endpoint saying it is complete. Then you would not have to wait for a timeout to move on with the process.