Troubleshooting Replication issues
Artifactory supports two types of replication: Push and Pull. Push replication is used to synchronize local repositories and can be triggered by events, as well as by configuring a cron expression. Pull replication is invoked by a remote repository, and runs according to a defined schedule to synchronize repositories at regular intervals. This solution is intended to troubleshoot some of the common issues that may appear during Replication.
[ERROR] – Unexpected EOF read on the socket
java.io.EOFException: Unexpected EOF read on the socket
Increase File Upload Max Size (MB) on the target.
[http-nio-8081-exec-1] [ERROR] – Could not retrieve list
Possible resolution, related to a known issue:
Disable/increase Tomcat timeout by specify the following attribute in the connector in $TOMCAT_HOME/conf/server.xml:
<Connector port="8081" sendReasonPhrase="true" connectionTimeout="-1"/>
Additional possible solution: local Filelist (related to internal issue- RTFACT-19064):
In Artifactory version 6.10.1 a new flag/system property is included:
artifactory.replication.push.fullTree.saveLocally=true/false (default: false)
(we can ignore the 'push' naming in the flag itself as it works for 'pull' as well)
When enabled, Artifactory will save the FileList to the filesystem under the Artifactory temp work directory – in a file called FullTree-[digits].json (by default, located under: $ARTIFACTORY_HOME/data/tmp/work).
This file will be deleted after the replication is done.
Without setting this flag, the default behaviour of replicating while streaming the file-list remains.
Mind that this may take considerable storage space (based on the number of replications, artifacts and folders stored).
It is recommended to separate different replications timing to avoid running them simultaneously if using this flag (in general – it's always advisable to separate different replications timing).
3. Source Artifactory
[ERROR] Error occurred while performing folder replication for ‘’: Could not retrieve remote file list for repo '' at '': HTTP/1.1 403 Forbidden
We may run this REST API call, which the replication performs behind the scenes, with the user configured for the replication. For example:
$ curl -u<ReplicationUser>:<password> http://artifactory_url/api/storage/libs-release-local/org/acme?list&deep=1&listFolders=1&mdTimestamps=1
In case the above results with a 403 response as well, we should check the permissions given to the replication user.
In case the above results with a 200 response, it means that a different user is configured for the replication authentication and we should check the request.log (for instance: the target request.log) and see which user appears in the relevant log entry. For example:
Example of a correlated log entry from artifactory.log of the source instance:
TIMESTAMP [replication-consumer] [ERROR] (o.a.a.c.BasicStatusHolder:211) – Error while deploying item 'RepoKey:PathToFIle on Url:http://artifactory_url/RepoKey ': Forbidden 
We should make sure that the user reaching the target has sufficient permissions to run the replication and it is not ‘anonymous’ (in case anonymous access is enabled).
General information about replication issues:
A.In general, in order to troubleshoot replication issues, we can add the following loggers (to the logback.xml file, located under: $ARTIFACTORY_HOME/etc/) in both: source and target Artifactory instances:
The above will add verbosity to the logs that are related to the replication process.
B.In order to try and prevent timeout issues during replication, we can disable any timeout configurations in the proxies, along with setting up a dedicated port and entry for the replication.