# rmi ssl zu große Objekte übergeben -> Exception



## Tallan (2. Okt 2009)

Hallo zusammen,

ich rufe per Server aus der DB ein longblob Feld mit 160 MB ab, dieses wird in einem bytearray gespeichert  (dafür wurde die heapgröße der vom mittels -mx1024M erhöt).
Nun möchte ich dieses Objekt per RMI als Parameter übergeben.
Leider kommt es dabei zu folgender Fehlermeldung :

java.rmi.MarshalException: error marshalling arguments; nested exception is: 
	javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset by peer: socket write error
....

Mit kleineren Datenmengen ( ein paar MB ) geht das ganze ohne Probleme.
Der Fehler tritt auf der Serverseite auf wenn der Server versucht dem Client die Daten als Parameter zu übergeben. 

Den Heapspace auf der Clientseite habe ich ebenfalls auf 1024M gesetzt das sollte also kein Porblem sein.
Es sieht für mich so aus als würde die SSL verbindung wegen der zu Großen Datenmenge getrennt werden?!?

Hat jemand diesbezüglich eine Idee?


----------



## tuxedo (2. Okt 2009)

Ja, wie wär's mit "nicht alles auf einmal lesen"...
An solche Blobs kommt man auch via Stream und kann häppchenweise lesen und somit auch häppchenweise mit RMI übertragen. 

btw: Sofern SSL nicht die Fehlerursache ist, müsste selbiges Szenario mit Simon funktionieren


----------



## Tallan (2. Okt 2009)

tuxedo hat gesagt.:


> Ja, wie wär's mit "nicht alles auf einmal lesen"...
> An solche Blobs kommt man auch via Stream und kann häppchenweise lesen und somit auch häppchenweise mit RMI übertragen.
> 
> btw: Sofern SSL nicht die Fehlerursache ist, müsste selbiges Szenario mit Simon funktionieren




daran hab ich auch schon gedacht allerdings ist mir dabei eine effektive umsetzung noch nicht ganz klar

Das ganze ist so angelegt das der Server die Daten aus der DB ausließt diese Prozess läuft in einem Thread welcher dann auf dem client eine Methode aufruft um sie zu übergeben, hierfür wird auf clientseite auch ein thread gestartet um die daten zu erhalten und verarbeiten.

Daher müssten bei einer häbchenweisen übergabe die Daten von thread an thread gesendet werden, geht das so einfach überhaupt?


----------



## SlaterB (2. Okt 2009)

ob man bei RMI überhaupt einen Stream übertragen kann ist schon ne interessante Frage,

auf jeden gehen müsste, die große Datei in 10 kleine zu übertragen und die beim Client zu sammeln + gegebenenfalls wieder zusammenzufügen,
oder falls die Daten Stream-artig verarbeitet werden: 
1/10 der Datei vom Server laden, in einen Stream speisen, 
falls dieser ausgelesen ist zweites Zehntel nachladen, wieder im Stream verfügbar machen usw.


----------



## tuxedo (3. Okt 2009)

RMI kann keine Streams. Deshalb auch der Vorschlag den Blob auf Serverseite als Stream anzuzapfen (statt komplett auf einmal alles zu lesen) und dann häppchenweise vom Stream lesen und diese Häppchen mit je einem Methodenaufruf zum Client zu schicken.

- Alex


----------



## maki (3. Okt 2009)

Gerade ergoogelt: RMIIO - Utilities for streaming data over RMI


----------



## tuxedo (3. Okt 2009)

Naja, ohne den RMIIO Code gesehen zu haben: Die Deckeln das häppchenweise übertragen einfach. RMI an sich ist nach wie vor nicht im Stande zu streamen. 

- Alex


----------



## Tallan (3. Okt 2009)

tuxedo hat gesagt.:


> Naja, ohne den RMIIO Code gesehen zu haben: Die Deckeln das häppchenweise übertragen einfach. RMI an sich ist nach wie vor nicht im Stande zu streamen.
> 
> - Alex



aber das wird doch sowieso in packeten übertragen und nicht an einem stück und die array größe selbst ist ja soweit auch ok da sowohl client als auch server damit umgehen können, es hängt eben nur an der übertragung


----------



## tuxedo (4. Okt 2009)

Wie groß ist denn das Array? Ich bin mir sicher du kannst 100Gbyte in 8192byte Päckchen mit RMI über SSL übertragen ....

Ob aber ein beliebig *großes* Array, welches auf Client oder auch Serverseite in den Heap passt am Stück übertragen werden kann weiß ich nicht.

Nebenbei: RMI ist nicht für große Datenübertragung gedacht/gemacht. Da ist zu viel Reflection und Proxy-technik drin als dass das wirklich super-performant läuft. 
Simon hat hierfür die "RawChannels". Da hat man nur den Protokoll-Overhead (glaub es waren/sind 9bytes pro Paket beliebiger Größe) und kein Reflection und Proxy mit involviert


----------



## SlaterB (4. Okt 2009)

wieviel Reflection ist denn bei einem einzigen byte-Array von 8 KB oder auch 8 MB wenn RMI das selber zerlegen kann?

große Datenmengen aus einzeln modellierten Objekten, das ist natürlich Arbeit, ob mit RMI oder sonstwen,
aber wenn es nur ein Objekt ist, ist dann ein riesiges Array nicht genauso aufwändig wie ein kleines String-Objekt, 
von der Übertragungsmenge abgesehen?


----------



## tuxedo (4. Okt 2009)

Reflection hat ja nix mit zerlegung oder der Art von Parametern zu tun. Bei RMI werden Methoden per Reflection und Proxys gesucht, gefunden und ausgeführt. Das kostet unnötig Zeit, auch wenn man primitive Übertragen will. 

Das was du meinst ist die Serialisierung. Bei primitiven wird da kein Object*Stream bemüht sondern wie bei Data*Stream direkt von und nach byte gewandelt. Das ist natürlich deutlich schneller. Aber der Methodenaufruf mit Reflection und Proxy findet nach wie vor statt. Und genau das kann SIMON mit seinen RawChannels besser.

- Alex


----------

