为什么大型存储库推送复制会失败

请注意:尽管本文讨论的是与推式复制相关的问题，但同样的故障排除建议也适用于此拉复制，其中您的目标服务器将是从中提取数据的服务器，而源服务器将是提取工件的服务器。

在开始调试这样的问题之前，需要了解复制机制是如何工作的。当存储库复制被触发时(无论是通过cron还是手动触发)，Artifactory将首先查询目标存储库以获得完整的复制文件列表．这是一个XML包含整个存储库内容的文件。使用这些信息，Artifactory然后确定哪些文件应该被复制，哪些文件应该被删除(假设您已经启用了同步删除选项)。

如果您的目标存储库包含大量文件(即一个巨大的文件列表)，或者如果您的源存储库缺少大量需要复制的文件，则可能会出现故障。原因是目标Artifactory在流中返回文件列表，Artifactory动态地检查每个条目，以检查文件是否丢失，是否需要复制或删除。

了解了复制过程的功能以及可能触发故障的原因后，您现在可以更好地了解调查你面临失败的真正原因。我们会建议两个场景你可能会看到:

注意:除了下面提到的参数外，在这两种场景中，我们都将增加复制设置中配置的套接字超时，以匹配我们将配置的超时值。

1.源Artifactory直接与目标Artifactory服务器通信，中间不使用反向代理或负载平衡器

在这种情况下，问题很可能与嵌入式Tomcat超时．所发生的是您的源Artifactory开始复制工件，并且在此期间不从流中读取。当这种情况发生时，在目标服务器上触发配置的超时设置并关闭连接，因为没有数据流。您可以通过增加超时值．的Artifactory连接器部分中添加以下参数$ ART_HOME / tomcat / conf / server.xml文件:

connectionTimeout = " > <秒"

我们建议从一个开始高价值的数字设置(如3小时)和监控你的复制之后。你的观察会让你知道减少还是增加这个设置是最好的。

2.源Artifactory使用反向代理或负载平衡器与目标Artifactory通信

这种情况有点复杂，因为您需要这样做确定正是你们之间的联系关闭并复位:

• 在目标服务器和负载均衡器/反向代理之间
• 在反向代理和源服务器之间