new BASE64Encoder().encode

[placebo76]

Wenn Strings > 10 MB mit dieser von Sun zur Verfügung gestellten Funktion encoded werden gibts ne heap-size Exception. Die Funktion soll aber auch nicht wirklich "offiziell" sein "sun.misc.*"

Gibt es da andere Möglichkeiten oder sind derartige Strings einfach viel zu groß ?

 

[AlArenal]

Nochmal: Die Sun-Packages sind nur für internen Gebrauch seitens Sun. Es gibt kein Garantie auf Kompatibilität oder auch nur auf bloße Existenz in verschiedenen JREs.

Nimm den Rat an, der dir an anderer Stelle gegeben wurde und nimm den Krempel aus der Apache Commons Encoder Lib: http://jakarta.apache.org/commons/codec/

Und wenn du ne Heap Size Exception bekommst dann, weil dein Prog nicht genug Speicher hat. Da man bei Applets - ohne dass jeder Client selbst in seiner Systemsteuerung frickelt - auf insgesamt 64 MB beschränkt ist, sollte man beim Filehandling in Applets auch entsprechend umsichtig agieren.

 

[placebo76]

kann

import org.apache.commons.codec.binary.Base64;

nich einbinden !?!

wenn ich das downgeloadete jar-file meinem einzigen anderen hinzufüge hab ich aber auch keinen Zugriff darauf :/

 

[AlArenal]

So lange du nicht genau beschreibst was du getan hast, ist es halbwegs schwer dir zu sagen, was du falsch gemacht hast.

 

[thE_29]

Nunja, ich sag mal so, wenn es wird herzlich egal sein ob du den interrnen sun Decoder nimmst oder den von Apache wenn du zuwenig Speicher zusagst!

Desweiteren wäre interessant welche IDE du hast

 

[placebo76]

Ich bekomme einfach das package nicht hinzugefügt umd ie Klassen zu nutzen.

Ich habe nur eine sehr kleine Anwendung mit einfachem Editor und ner Console zum kompilieren ;-)

Wie sage ich denn mehr Speicher zu? ich denke das ist Clientabhängig?

 

[AlArenal]

Im falle eines Applets ist die Speicherzuweisung unter Windows nur über das Java-Plugin der Systemsteuerung änderbar.

Im Falle einer normalen oder Webstart-Anwendung gibts die passenden Parameter/Schalter ( -Xmx, -Xms ).

Nun wissen wir immernoch nicht was du (nicht) getan hast.

 

[placebo76]

Da meine Zeit leider begrenzt ist hab ich jetzt einfach die 6 nötigen Klassen meiner jar-Datei hinzugefügt :/

Habe dafür na Batch-Datei

z.B.:

javac Decoder.java
jar cf0 ... Decoder.class

 

[thE_29]

Tjo und gehts jetzt?
In den FAQ ist auch beschrieben wie man jars zusammenpackt! (falls du keine IDE hast)

 

[placebo76]

Ja läuft jetzt, aber wie AlArenal schon erwähnte, das HeapSize Problem bleibt.

Ich lese lediglich eine 15MB große Datei ein, encodiere sie Base64 und mache dann noch ein

URLEncoder.encode(base64String)

danach gibt es die heapsize-exception

 

[thE_29]

Tjo, auf webstart umschwenken, wenn es ein Applet ist!

Willst du die Datei rumschicken oder wozu das base64?

 

[placebo76]

Soweit ich weiß funktioniert das bei nem Webstart nicht das sich aus ner HTML-Seite Parameter entgegennehme oder?

Genau, ich schicke die Datei an ein PHP-Skript, dass die Daten weiterverarbeitet.

Kann man denn bei den 3 von mir genannten Vorgängen irgendwas anders machen? Ich meine da können doch nicht 64 MB für draufgehen ...

Nehmen die Objekte irgendwie Speicherplatz ein den ich vor der nächsten Operation irgendwie wieder freigeben könnte?

 

[AlArenal]

Soweit ich weiß funktioniert das bei nem Webstart nicht das sich aus ner HTML-Seite Parameter entgegennehme oder?

Sicher funktioniert das. Nirgends steht geschrieben, dass die JNLP-Datei nicht dynamisch generiert werden kann. Machen wir auch nicht anders...

Kann man denn bei den 3 von mir genannten Vorgängen irgendwas anders machen? Ich meine da können doch nicht 64 MB für draufgehen ...

Du sprachst eingangs von Dateien über 10 MB. Grundsätzlich musst du ja mit einem Worst Case Szenario rechnen. Wenn du die Datei erst ganz einliest, diese in einen String stopfst und diesen dann Base64-kodierst hast du schonmal mindestens einen Bedarf für 2 1/3 der Größe der Originaldatei und da ist noch kein Byte Verwaltungs-Information, Code, oder sonstwas eingerechnet.

Sinnigerweise würde man die Datei Stück für Stück einlesen, kodieren und verschicken und erst serverseitig zusammenfügen, wenn alles korrekt und vollständig übermittelt wurde. Nur so kann der Speicherverbrauch der Anwendung von der Größe der zu übermittelnden Datei entkoppelt werden.

Lustig, dass ich gerade für diesen Zweck vor zwei Jahren mal eine auf XML-RPC aufbauende Lib schreiben wollte. Über die Planungsühase und erste Gedanken zum Aufbau des Protokolls kam ich aber wie so häufig nie hinaus. Mittlerweile würde ich zusätzlich auch noch JSON in Betracht ziehen.. naja.. egal..

 

[byte]

URLEncoder.encode(base64String)

Es ist furchtbar inperformant, mit so großen Strings zu arbeiten. Versuchs doch mal mit URLCodec.encode() aus den Jakarta Commons. Die akzeptiert auch Byte-Arrays. Ansonsten halt wie AlArenal sagte splitten.

 

[placebo76]

Splitten wäre eine Idee,

zusammenbauen muss ich sie jedoch vor dem Senden wieder, denn ich kann ja nur einen Request senden

 

[AlArenal]

Splitten wäre eine Idee,

zusammenbauen muss ich sie jedoch vor dem Senden wieder, denn ich kann ja nur einen Request senden

Warum?

 

[placebo76]

Splitten wäre eine Idee,

zusammenbauen muss ich sie jedoch vor dem Senden wieder, denn ich kann ja nur einen Request senden

Warum?

Also ich meine jetzt wirklich einen Request senden, da sonst das Zielskript erneute aufgerufen wird, und der Aufwand dass dann zu handlen ist ein bißchen groß.

Innerhalb eines Request die Daten zerstückelt zu schicken geht natürlich, aber ich glaube da würde es ja auch keinen Unterschied machen ob an einem Stück oder nicht.

Probiere jetzt erstmal den De/Encode-Funktionen die Daten in Teilen zu liefern