it-swarm.com.de

Beim Aktualisieren vom SVN-Repository wird der Fehler "Blockgröße konnte nicht gelesen werden"

Beim Update vom Subversion-Repository mit dem Tortoise-svn-Client bekomme ich einen Fehler, der folgendermaßen aussieht:

Could not read chunk size: An existing connection was forcibly closed by the remote Host.

Es hindert mich nicht an der Aktualisierung, sondern unterbricht nur den Aktualisierungsvorgang, sodass ich die Aktualisierung mehrmals wiederholen muss, bevor sie abgeschlossen ist.

Was kann ein solches Verhalten verursachen und wie kann es behoben werden?

54
Denis

Ich erhielt die Meldung "Blockgröße konnte nicht gelesen werden" von Clients auf mehreren Computern.

Der Schlüssel dazu war dieser Fehler im Apache-Fehlerprotokoll:

[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Provider encountered an error while streaming a REPORT response.  [500, #0]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Problem replaying revision  [500, #24]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Can't open file '/usr/site/svnrep/impc/db/revs/16122': Too many open files  [500, #24]

Dem Apache-Prozess, der die svn-Operation abwickelt, sind die Dateideskriptoren erschöpft. Auf meinem Ubuntu-Server habe ich das Problem behoben, indem ich /etc/security/limits.conf editierte und dies am Ende hinzufügte:

*               hard    nofile          5000
*               soft    nofile          5000

Dadurch wird das Dateideskriptorenlimit von 1024 auf 5000 erhöht. Dann habe ich mich bei einer neuen Shell angemeldet und mit ulimit -n bestätigt, dass das Limit erhöht wurde. Dann wurde Apache neu gestartet.

14
Lachlan

Ich habe gerade den Fehler "Chunk Size konnte nicht gelesen werden" erhalten UND EINE LÖSUNG GEFUNDEN - zumindest für ein Szenario.

Zuerst meine Konfiguration ...

SERVER: CollabNet Subversion Edge Server 2.0.0-2190.74 (Subversion-Binärdateien 1.6.17-2190.74) wird unter Windows Server 2003 32-Bit ausgeführt.

KLIENT: TortoiseSVN 1.6.16, Build 21511 - 32-Bit (Subversion 1.6.17) unter Windows XP Pro 32-Bit mit SP3.

Schritte zum Reproduzieren...

Ich habe diese Fehlermeldung erhalten, nachdem ich mit der rechten Maustaste einen versionierten Unterordner in einen anderen versionierten Unterordner innerhalb meines lokalen Arbeitskopieordners gezogen und dann ausgewählt habe 'Versionsnummer (e) von SVN-Kopien hier' (Dies ist ein TortoiseSVN-Kontextmenübefehl in Windows Explorer, wenn Sie Ordner mit der rechten Maustaste ziehen). Der Unterordner enthielt eine ANSI-codierte Textdatei, MANIFEST.MF, die meiner Meinung nach nicht geändert wurde (meine Subversion-Konfiguration enthält keinen Mime-Typ für .MF-Dateien). Ich habe anschließend den neu kopierten Unterordner festgelegt. Jedes Mal, wenn ich versuchte, meine lokalen Arbeitskopie-Ordner von Subversion auf diesem PC zu aktualisieren, wurde der Chunk-Size-Fehler angezeigt.

Abhilfe ...

Ich habe dies behoben, indem ich meinen Subversion/Apache-Dienst (der an und für sich nicht geholfen hat und möglicherweise nicht notwendig war) neu startete löschen des neu hinzugefügten Unterordners aus meinem lokalen Arbeitskopienordner (es hatte es schon zum Repo geschafft, also würde ich nichts verlieren), und dann ein Update durchführen, das ohne den Chunk-Size-Fehler erfolgreich war und den gerade gelöschten Unterordner wieder holte. 

In meinem Fall hatte ich ZWEI versionierte Unterordner auf diese Weise kopiert, und ich konnte das Stammverzeichnis meines lokalen Arbeitskopieordners nicht erfolgreich aktualisieren, bis ich BEIDE dieser neuen Unterordner gelöscht hatte.

Nachverfolgen...

Ich gehe davon aus, dass dies ein Fehler im Subversion-Server und/oder TortoiseSVN-Client ist, aber ich habe nicht die Fähigkeiten zum Debuggen, um diese Entscheidung zu treffen. Ich werde meine Ergebnisse im TortoiseSVN Issue Tracker melden und sehen, wohin das führt.

11
MikeOnline

Ich hatte das gerade mit mir passiert und es war nicht ein Serverproblem; meine Arbeitskopie wurde (von mir übrigens) beschädigt.

10
hoffmanc

Das Problem und (einige andere) verschwanden nach dem Deaktivieren des clientseitigen Virenschutzprogramms. 

Ich benutze Ubuntu Server mit Subversion 1.7.4 über Apache.

7
vrogach

Für uns war das Problem ein Timeout bei Apache. Das Update dauerte etwa 15 Minuten, aber nach 10 Minuten war der Apache abgelaufen, wodurch der SVN-Server den Fehler ausgegeben hat. Die letzte Lösung bestand darin, die Timeout-Einstellung für Apache zu erhöhen. Wir verwenden den VisualSVN-Server. Eine detaillierte Anleitung zum Ändern dieser Einstellung finden Sie hier: http://adventuresindotnet.blogspot.com/2010/09/svn-trouble.html

2
CodeThug

Überprüfen Sie das Apache-Fehlerprotokoll. Dort sollte ein Fehler mit einer Fehlernummer protokolliert werden. Diese Nummer hilft dabei herauszufinden, warum die Verbindung getrennt wurde.

Wenn im Fehlerprotokoll nichts enthalten ist, überprüfen Sie die Einstellungen Ihres Virenscanners/der Firewall: Einige dieser Tools trennen eine Verbindung, wenn sie der Meinung sind, dass die übertragenen Daten gefährlich sind.

2
Stefan

Ich habe diese Fehlermeldung bei Updates erhalten, nachdem ich einen Ordner umbenannt und festgeschrieben hatte. Ich habe ein neues Arbeitsverzeichnis erstellt und den Fehler nicht erhalten. Also habe ich meine Änderungen einfach in das neue Arbeitsverzeichnis verschoben, das alte Verzeichnis festgeschrieben und weggeblasen.

Dieser Fehler schien also darauf zurückzuführen zu sein, dass mein lokales Verzeichnis beschädigt wurde.

1
user1097928

Ich habe auf einen Ubuntu-Server gewechselt und wir hatten denselben Fehler - bei mehreren Client-PCs, Betriebssystemen und Client-Versionen.

Nachdem Sie sich vergewissert haben, dass sowohl die Einstellungen für das Dateilimit als auch die Apache-Timeout-Einstellungen wie vorgeschlagen waren.

(Siehe http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/ )

Ich löste das Problem schließlich, indem ich das Paket Apache2-mpm-prefork anstelle des Pakets Apache2-mpm-worker verwendete.

1
Simon Hoffe

Das verstehe ich auch Unser Server ist Apache, der unter Windows läuft. Mein Client ist mit einer hohen Geschwindigkeit verbunden, jedoch mit einer relativ hohen Latenzzeit (200 ms). Der andere Teil des Puzzles ist, dass ich Windows Vista verwende. Das Drehen von Autoscaling und RSS scheint die Situation zu verbessern, aber es nicht zu beheben.

0
Jeremy White

Es gibt eine andere ärgerliche Ursache für diese Fehlermeldung. Dies kann Ihr Router oder die Firmware Ihres Routers sein.

Ich hatte kürzlich die Firmware meines Linksys WRT110 von Version 1.0.02 auf 1.0.07 aktualisiert. Danach konnte Subversion keine neuen Dateien mehr zum Repository hinzufügen. Es können nur vorhandene Dateien aktualisiert werden. Durch das Zurücksetzen auf 1.0.02 wurde das Problem behoben.

Quellen:

Jedes Mal, wenn die Verbindung abrupt unterbrochen wird, wird dieser Fehler angezeigt. Es könnte ein Konfigurationsfehler auf Apache sein, wie viele von Ihnen angaben. Es könnte auch an einem langsamen Server oder einer überlasteten Verbindung liegen oder an einem billigen Router, wie in meinem Fall.

0
mrbinky3000

Für uns war die Problemumgehung, den SVN client von 1.8 auf 1.7 downgrade (Befehlszeilen-Client, der mit TortoiseSVN gebündelt ist).

0
Frank Schmitt

Dies hat eindeutig viele Ursachen, aber für mich wurde dies durch einen Neustart meines SVN-Servers (VisualSVNServer 2.5.1) behoben. Dies tritt häufig auf, wenn eine vollständige Repo-Überprüfung für einen neu geladenen Speicherauszug durchgeführt wird.

0
Derrick

VisualSVN 2.5.8: Hatte den gleichen Fehler, die nächsten Schritte halfen mir, diesen Fehler zu beheben:

Auf dem Server:

  1. Im problematischen Ordner des Servers gelöscht; 
  2. Starten Sie den VisualSVN-Server neu.

Auf der Workstation:  

  1. Aktualisieren Sie den übergeordneten Ordner.
  2. Ordner und Dateien erneut hinzufügen;
  3. Zu SVN hinzufügen;
  4. Verpflichten.
0
Eugene Bosikov