Une commande SVN volumineuse échoue sporadiquement
Je rencontre actuellement des problèmes lors d'une extraction complète du référentiel SVN (20 Go +), où le processus de commande s'interrompt de manière aléatoire. Le référentiel est composé de nombreux petits fichiers texte et de quelques gros fichiers CSV.
Il est difficile de cerner le problème car l'erreur ne survient que quelques heures après le paiement. D'après ce que j'ai vu, ce n'est pas un fichier spécifique qui arrête le processus et la vérification à l'aide de svnadmin n'a renvoyé aucune erreur.
Les erreurs:
Journal des erreurs Apache typique:
Unable to deliver content. [500, #0]
Unable to deliver content. [500, #0]
Could not write data to filter. [500, #175002]
Could not write data to filter. [500, #175002]
Provider encountered an error while streaming a REPORT response. [500, #0]
A failure occurred while driving the update report editor [500, #730053]
Spécifications:
Serveur: Windows Server 2003 exécutant XAMPP v1.8.2-5, Apache v2.4 et SVN v1.8.9. Il a été récemment mis à jour à partir d'Apache 2.2 et de SVN 1.5.3, qui rencontraient des problèmes similaires.
Clients: Windows 7 exécutant TortoiseSVN v1.8.8 x64, récemment mis à jour à partir de la version 1.8.3 x64, qui rencontrait des problèmes similaires. SVN en ligne de commande v1.8.9.
J'utilise le protocole HTTP pour effectuer le paiement.
Ce que j'ai essayé:
Définir la directive "TimeOut" sur Apache sur une valeur plus élevée (jusqu'à 30000 secondes).
Définir la directive "SVNAdvertiseV2Protocol" sur off.
Désactiver la directive "SVNPathAuthz".
Paramétrer la directive "SVNCompressionLevel" sur "0".
Nous avons rencontré ce même problème récemment. Jusqu'à présent, je pense que cela a été lié aux nouveaux clients Subversion.
Directive Apache dav_svn_module
SVNAllowBulkUpdates Prefer
Semble aider. Après avoir ajouté cela dans Apache conf, aucun problème n'a été trouvé. Auparavant, la plupart des grosses caisses avaient échoué.
J'ai trouvé un fil de discussion qui explique les problèmes liés aux clients Subversion plus récents que la version 1.8.x. Voir le fil de la liste de diffusion.
J'ai eu les erreurs suivantes:
Unable to deliver content. [500, #0]
Could not write data to filter. [500, #175002]
Je n'ai même pas utilisé le mod_deflate, donc ça ne pouvait pas être ça. Dans mon cas, c’est l’authentification (auth_digest_module) à l’origine de l’erreur. Si une checkout dure plus de 300 secondes, l'erreur ci-dessus serait consignée dans mon journal de serveur Apache.
Le problème est la directive par défaut AuthDigestNonceLifetime 300. Voir ici . Ma solution a été de définir cette directive à l'infini: AuthDigestNonceLifetime -1
Cela semble être un problème d’encodage des fichiers selon cet article sur la liste de diffusion Subversion. Vous pouvez rechercher des entrées AddEncoding x-gzip .gz dans votre configuration Apache et les supprimer ou les ajouter à votre entrée <Location /svn>…</Location>:
RemoveEncoding .gz
RemoveEncoding .Z
Ceci a été mentionné dans le changelog , mais je ne me suis pas soucié de le lire et je l’ai appris à la dure…
J'ai rencontré le même problème en essayant de faire une extraction snv sur un référentiel de taille moyenne (500 Mo) en utilisant un serveur composé de clients Centos 7.4.1708, Apache 2.4.6, Subversion 1.9.15 et Windows 10 en utilisant TortoiseSVN 1.9.7 de derrière un proxy inverse Apache.
La solution pour moi consistait à ajouter SVNAllowBulkUpdates Off similaire à la réponse de teori. J'ai essayé d'utiliser " SVNAllowBulkUpdates Prefer ", mais lorsque j'ai redémarré httpd, une erreur s'est produite indiquant que " SVNAllowBulkUpdates doit être activé ou désactivé ". Mon fichier de configuration final SVN/Apache est:
<Location/svn> DAV svn SVNParentPath /svn SVNAllowBulkUpdates Off AuthType Basic AuthName "SVN Repo" AuthUserFile /var/svn/svn-auth-user Requiert un utilisateur valide </ Location >
Autres réflexions: Je ne crois pas que les paramètres Timeout et AuthDigestNonceLifetime sont directement liés au problème. J'ai essayé de les utiliser, mais je n'ai eu aucun effet. J'ai spécifiquement expérimenté les paramètres timeout, keepalive et keepalivetimeout sur l'hôte SVN et l'hôte proxy inverse.
Le problème peut être lié au "dégonflage", mais je l’ai aussi désactivé comme suggéré par Tim S. et cela n’a pas non plus d’effet. La raison pour laquelle je pense toujours que cela pourrait être lié est que, après avoir éliminé l'erreur, j'ai remarqué que le nombre d'octets transférés était considérablement plus grand qu'auparavant.