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

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

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

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

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

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

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

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

connectionTimeout = " > <秒"

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

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

这种情况有点复杂，因为您需要这样做确定正是你们的联系闭合复位：

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