Hallo!

Ich bekomme einen OutOfMemoryError Fehler, sobald ich versuche eine Datei, die
größer ist als ca. 3MB mit einer Put-Methode auf einen WebDav-Server hochzuladen.

Beispielscode:

import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.PutMethod;

HttpClient client = new HttpClient();
Credentials creds = new UsernamePasswordCredentials("userId", "pw");
client.getState().setCredentials(AuthScope.ANY, creds);

PutMethod put = new PutMethod("http://IrgendeinServer/Basisordner/test.txt");
RequestEntity requestEntity = new InputStreamRequestEntity(new
FileInputStream("/path/to/file/test.txt"));
put.setRequestEntity(requestEntity);

client.executeMethod(put); //<-- da steigt er aus


Ich hatte ein ähnliches Problem bei HTTP Multipart Post. Da hat es geholfen
den Stream (ich glaube das war FileOutputStream), mit dem er den Inhalt der
Datei in die Anfrage schreibt, auf BufferedOutputStream umzustellen.

Hier kann ich den OutputStream leider nicht beeinflussen.

Die Größe des JavaHeaps zu erhöhen hat seltsamerweise auch nichts gebracht.

Hier ist noch die Fehlermeldung:

Exception in thread "Thread-5" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.lang.AbstractStringBuilder.expandCapacity(Unk nown Source)
at java.lang.AbstractStringBuilder.append(Unknown Source)
at java.lang.StringBuffer.append(Unknown Source)

Hätte jemand eine Idee, wie ich das Problem lösen könnte?

Gruß, Juri

Juri Ivanov <Juri.Ivanov*medizinische-genetik.de> wrote:
> RequestEntity requestEntity = new InputStreamRequestEntity(new
> FileInputStream("/path/to/file/test.txt"));
> put.setRequestEntity(requestEntity);
> client.executeMethod(put); //<-- da steigt er aus

Probier mal ein FileRequestEntity. Aber so oder so sollte das in den HEap
passen.

Gruss
Bernd

Bernd Eckenfels schrieb:

>> RequestEntity requestEntity = new InputStreamRequestEntity(new
>> FileInputStream("/path/to/file/test.txt"));
>> put.setRequestEntity(requestEntity);
>> client.executeMethod(put); //<-- da steigt er aus
>
> Probier mal ein FileRequestEntity. Aber so oder so sollte das in den HEap
> passen.

Ach, diese Apache-Sachen sind teilweise so schlimm Programmiert dass sie
nur begrenzt einsetzbar sind.

Zb. dass man ASCII in char statt in byte ablegt *fg*

Das Problem scheint zu sein, dass irgendwo mit zu kleinen Buffern
gearbeitet wird, daher der Content arg fragmentiert läuft und der
StringBuffer daher immer nur in kleinen Schritten erweitert wird.

Testet man das lokal, wird sehr schnell viel Schrott auf dem Heap
erzeugt dass die GC nicht mehr nachkommt.

Was mich hier total stutzig macht ist der Stacktrace: zumindest bei mir
(Java 5 oder 6?) nimmt StringBuffer in .append(..) sein eigenes
.ensureCapacity(...) und ruft darin System.arraycopy(...) auf - was der
Quatsch über AbstractStringBuilder und Array.copyOf(..) soll, ist mir
schleierhaft und wäre imho eine derbe Performancebremse.

Bernd

--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean.oliver*nixwill.de & bernado.bernhardi*spammichvoll.de

Bernd Hohmann <bernd.hohmann.20090228*freihaendler.com> wrote:
> Testet man das lokal, wird sehr schnell viel Schrott auf dem Heap
> erzeugt dass die GC nicht mehr nachkommt.

Nein das kann nicht sein. Vor einem OOM wird ein Stop the World FullGC
gemacht. (Vorausgesetzt der passiert nicht ständig wegen memleak führt das
dann nicht zu einem OOM wenn man zu viele Objekte zu schnell anlegt)

Gruss
Bernd

Am 04.11.2009, 15:21 Uhr, schrieb Juri Ivanov
<Juri.Ivanov*medizinische-genetik.de>:

> Ich bekomme einen OutOfMemoryError Fehler, sobald ich versuche eine
> Datei, die größer ist als ca. 3MB mit einer Put-Methode auf einen
> WebDav-Server hochzuladen.
>
> [...]
>
> Hier ist noch die Fehlermeldung:
>
> Exception in thread "Thread-5" java.lang.OutOfMemoryError: Java heap
> space
> at java.util.Arrays.copyOf(Unknown Source)
> at java.lang.AbstractStringBuilder.expandCapacity(Unk nown Source)
> at java.lang.AbstractStringBuilder.append(Unknown Source)
> at java.lang.StringBuffer.append(Unknown Source)
>
> Hätte jemand eine Idee, wie ich das Problem lösen könnte?

Die Ursache des Problems muss nicht zwingend dieser Aufruf sein. Das Opfer
ist er allemal.

Um den Täter zu finden, würde ich die VM mit

-XX:+HeapDumpOnOutOfMemoryError

starten und den erhaltenen Dump mit jhat analysieren.

--
Gruß,
Alex

Alexander Veit <alexander.veit*fernuni-hagen.de> wrote:
> starten und den erhaltenen Dump mit jhat analysieren.

oder Eclipse MAT

Gruss
Bernd

Bernd Eckenfels schrieb:

> Alexander Veit <alexander.veit*fernuni-hagen.de> wrote:
>> starten und den erhaltenen Dump mit jhat analysieren.
>
> oder Eclipse MAT

oder VisualVM (das ist so weiß ich weiß der Profiler aus Netbeans in eiener
Standolone-version):

https://visualvm.dev.java.net/

Robert

Robert Kochem <robert*mailueberfall.de> wrote:
> oder VisualVM (das ist so weiß ich weiß der Profiler aus Netbeans in eiener
> Standolone-version):
>
> https://visualvm.dev.java.net/

Ne das ist der JConsole nachfolger. Aber um Heap Dumps zu analysieren ist
MAT ungeschlagen.

Gruss
Bernd