我有一个端点，它有一个消息处理程序，可以完成一些FTP工作。 由于ftp进程可能需要一些时间，因此我在TransactionScope中使用TransactionScopeOption.Suppress封装了ftp方法，以防止事务超时异常。
这样做摆脱了超时异常，但处理程序被解雇了5次 （我的配置文件中的重试次数设置为5）
这些文件是ftp确定的，但它们只是ftp了5次。
处理程序看起来像是在10或11分钟后重新启动。
一些测试代码如下所示：
public void Handle(FtpMessage msg)
{
using (TransactionScope t = new TransactionScope(TransactionScopeOption.Suppress))
{
FtpFile(msg);
}
}
非常感谢任何帮助。
感谢。
答案 0 :(得分：2)
如果这真的是一个无法在事务超时内完成的FTP通信，另一种方法是将其转换为Saga。
Saga将由FtpMessage启动，并且在处理程序中它将异步启动FTP工作，无论是在另一个线程中，还是通过另一个进程，或者其他什么，并在saga数据中存储足够的信息以便能够查找后来进步。
然后它会从TimeoutManager请求超时，无论多长时间都有意义。收到超时后，它将在saga数据中查找状态，并检查正在进行的FTP工作。如果已完成，请将传奇标记为完成，否则请求另一个超时。
或者，您可以拥有一个包装FTP通信的进程，该进程拥有自己的总线，但没有自己的任何消息处理程序。它可以通过命令行（包括请求端点）接收其FTP信息，完成其工作，然后将消息发送回请求端点，说明它已完成。然后你不必等待超时继续进行该过程。
答案 1 :(得分：2)
我建议将该端点配置为非事务性而不是尝试禁止事务。如果是自托管，或者在使用通用主机时通过实现IConfigureThisEndpoint，AsA_Client，请在初始化代码中包含.IsTransactional（false）。
答案 2 :(得分：0)
我的猜测是，如果没有完成内部作用域，则会导致由NSB创建的外部作用域进行回滚。这将导致NSB重试您的FtpMessage。
尝试添加：t.Complete（）;在你打电话给FtpFile后，看看是否适合你。
编辑：在重新阅读您的问题后，我意识到这不会解决您的超时问题。你试过增加超时吗？ （10分钟是machine.config中的默认maxValue，因此如果不修改machine.config就无法将其设置为更高）