[Tomcat] hängt am Ende von Upload via PUT



Hallo,

wir haben hier einen selbstgeschriebenen WebDAV Server auf
Tomcat 5.5.12 zu dem wir regelmaessig Backup Daten (bis zu 10GB)
übertragen. Soweit läuft alles prima wie geplant.

Aber manchmal - jedoch ausschliesslich am Wochenende - bleibt
der Request im Tomcat am Ende der Übertragung stehen.

Wir verwenden einen eigenen Client (in Haskell geschrieben)
für die Übertragung via PUT. Die Content-Length wird als
Long Wert definiert und vom Servlet selbsttätig ausgewertet.

Wie erwartet passen die Werte auch unter allen Bedingungen
zueinander. Für die Übertragung ist eine Routine "copyStream"
zuständig, welche mittels eines 8kByte byte[] Puffer mit

int len = servletInputStream.read(buffer, 0, buffer.length)

Daten liest und mit

fileOutputStream(buffer, 0, len) runterschreibt.

Die Menge der jeweils gelesenen Daten wird mitgezählt.
Sinkt die verbleibende Menge Daten unter die Buffersize so
wird bei read nur noch die kleinere Differenz von ContentLength
und übertragenen Daten an Stelle der Puffergrösse verwendet.

Wir dachten so ein evtl. blockendes read() zu eliminieren.

Sind alle Daten gelesen und geschrieben, so wird direkt im
Anschluss fileOutputStream.close() gerufen und der Request
ist beendet.

Und jetzt kommt Murphy ins Spiel:

Bei diesen "Hängern" sind die Files auf der Platte gelockt,
d.h. fileOutputStream.close() wurde nicht gerufen.
Es gibt für alle Eventualitäten Log Messages und try/catch
Konstrukte. Wir erhalten keine auffälligen Messages aus
diesem und den umgebenden Codeblöcken.

Jedoch sind die Files komplett, d.h. bis aufs letzte Byte
der 10GByte vollstaendig intakt. MD5 und SHA1 Prüfsumme
sind identisch.

Tomcat ist mit 'disableUploadTimeout="true"' konfiguriert,
Übertragungsweg ist HTTP ohne SSL/TLS und connectionTimeout
und socket linger sind auf default, d.h. 60s und deaktiviert.
Dennoch bleibt der Request sozusagen stehen und die Files
bleiben gelockt. Tritt dies einmal auf, so sind alle nach-
folgenden Uploads plötzlich vom selben Effekt betroffen bis
Tomcat neu gestartet wird - dann ist der Spuk vorbei.

Wie gesagt, dass Phänomen lässt sich nur am Wochenende blicken
wenn keiner in der Firma ist. Der Server steht im RZ, die
anderen Rechner welche Backups übertragen wollen befinden sich
im selben Netz, jedoch nicht zwingend im selben Raum.
Der Leitungsweg dazwischen sollte am dünnsten Punkt 100MBit/s
haben, vollständig geswitcht.

Ich bin nach wochenlanger Suche etwas ratlos wo ich
überhaupt weiter suchen soll.
Hat vielleicht jemanden einen Tipp?
Danke.

Viele Gruesse,
Christian
.



Relevant Pages

  • [REVS] NTLM HTTP Authentication is Insecure By Design
    ... in front of a web server, and that proxy server shares a single TCP ... These are attacks that make use of non-RFC HTTP requests (HTTP Request ... the authentication is associated with the ...
    (Securiteam)
  • [NT] 04WebServer Multiple Vulnerabilities (CSS, Log File Injection, AUX DoS)
    ... 04WebServer is a HTTP server developed by Soft3304 for Windows platforms. ... Characters into Log File ... filtering on the request URL before writing it into the log file. ... following HTTP request, when submitted to a vulnerable 04WebServer, will ...
    (Securiteam)
  • Re: breaking the model
    ... > The forms data then is in the Request object. ... HTTP Request; in this case, the form POST Request from the Page. ... client and server. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: SRCP Protokoll Lexik
    ... Encoding of SRCP Messages ... by the numeric value of the character. ... Information sent by the server is subject to the same terms. ... Replies and Information Messages are always proceeded by a time stamp. ...
    (de.rec.modelle.bahn)
  • Re: Anonymous Anonymity - Request For Comments
    ... > and request that you reply directly to my e-mail address. ... > for the entity wishing to preserve their anonymity. ... > the machine can perform as a Intermediary Server and / or as a Intermediary ... > The software then attempts connection to a Intermediary Server. ...
    (Bugtraq)

Loading