Problem mit ByteArrayInputStream

[Andreas1989]

Hallo zusammen,

ich habe folgende Thematik:
In meinem Programm existieren zwei Threads die über eine Pipe Daten austauschen wollen. Genauer gesagt wird ein Objekt vom Typ DataBase(selbst erstellt) in einem Thread immer dann neu erstellt, wenn eine gewisse Text Datei neu gespeichert wurde. Das Objekt soll dann nun über die Pipe an den anderen Thread geschickt werden, welcher für die Auswertung zuständig ist. Dabei ist die Textdatei ca. 30 kByte groß.

Meine Vorgehensweise war nun im Sender aus meinem DataBase ein File Array zu erzeugen. Das mach ich so:

ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutput out = new ObjectOutputStream(bos);   
out.writeObject(dataBase);
byte[] yourBytes = bos.toByteArray();

Das Array mit 24181 Feldern schicke ich dann über die Pipe an den anderen Thread. Dort kommt es auch an und wird korrekt als neues byte array mit 24181 Feldern zusammen gesetzt.

Wenn ich aber im Auswerter versuche mir aus dem byte array wieder ein DataBase Objekt zu erzeugen bekomme ich eine "java.io.StreamCorruptedException: invalid type code: 00" Exception.

Dabei gehe ich so vor:

ByteArrayInputStream bis1 = new ByteArrayInputStream(datas);
ObjectInputStream in1 = new ObjectInputStream(bis1);
Object temp = in1.readObject();// Hier kommt die Exception

Das komische ist, wenn ich den gleichen Code in den ersten Thread kopiere und mir dort aus dem generierten byte array ein DataBase Objekt erstelle, wird keine Exception geworfen und ich bekomme ich Objekt vom Typ DataBase.


An was kann das liegen? kann durch eine Pipe Verbindung falsche Daten übertragen worden?
Ich habe bis jetzt stichproben weise das zusendende mit dem empfangem array verglichen und bis jetzt sieht alles super aus.
Ich kann es mir aber nicht erklären, warum einmal eine Exception geworfen wird und einmal nicht, wenn es sich um das eigendlich gleiche array handelt..


Wär super wenn mir jemand weiter helfen könnte. Bin grad echt etwas am verzweifeln...


Grüße
Andi

 

[rme]

Hallo,

bitte erstell mal ein lauffähiges Minimalbeispiel, in dem das Problem auftritt, damit man das selbst testen kann. Denn deine Beschreibung klingt nach einem korrekten Vorgehen.

Nebenfrage: Warum gehst du den Umweg, das Objekt zu serialisieren und direkt wieder zu deserialisieren, obwohl es im gleichen Prozess passiert? Könntest du das Objekt nicht direkt in die Pipe schreiben?

 

[Andreas1989]

Hallo,
erst mal danke fürs Feedback.
Habe das Programm mal stark vereinfacht und lade nun einfach mal das ganze Netbeans Projekt hoch.
Ich hoffe du kannst damit was anfangen.

Interessant ist nun, das die Kommunikation nun manchmal funktioniert - manchmal aber immer noch eine StreamCorruptedException geworfen wird. Für mich sieht das so aus, als ob die Daten bei der Übertragung durchaus "beschädigt" werden. Kannst du das bestätigen?

Zu deinem zweiten Punkt. Ich habe heute das erste mal eine Pipe verwendet. Und da ich mit dem PipedOutputStream / PipedInputStream scheinbar nur byte[] oder int schicken kann, bin ich davon ausgegangen, dass ich mein Objekt zuerst serialisieren muss um es über die Pipe zu übertragen. Oder gibt es da noch eine Möglichkeit?

Wenn es dir hilft, kann ich auch die einzelnen Stellen zu der Pipe hier rein kopieren.

Nochmal vielen dank für deine Hilfe.

Lg Andi

 

[rme]

Hallo,

das Problem ist glaube ich, dass der schreibende Thread manchmal unterbrochen wird, während die Daten geschrieben werden, d.h. das Array wird nur teilweise geschrieben, was dann einen Fehler im lesenden Thread erzeugt. Du müsstest vorher die genaue Länge wissen, damit du das Array korrekt einlesen kannst. Also zum Beispiel vor dem Array immer einen int mit der Länge schreiben - dann kann der Leser erst die Länge lesen und weiß danach, wie viel er aus den nächsten Daten lesen muss, bis er fertig ist.

Aber wie gesagt, innerhalb eines Prozesses ist Serialisierung eine sehr schlechte (da sehr langsame) Idee. Wenn du genauer beschreiben kannst, auf welche Weise die Threads kommunizieren sollen, kann ich dir vielleicht eine bessere Klasse empfehlen. Also eine Beschreibung in der Art: "Der lesende Thread soll auf 'Arbeit' vom Schreibenden warten, d.h. er schläft die meiste Zeit, bekommt ab und zu Arbeit und legt sich danach wieder schlafen, bis neue Arbeit kommt". Dies wäre beispielsweise mit einer BlockingQueue sehr einfach zu lösen.

 

[Andreas1989]

Also ich habe folgendes vor:

In meinem ersten Thread, möchte ich jede Sekunde prüfen ob eine gewisse txt-Datei aktualisiert wurde.
Sobald ich feststelle dass die Datei aktualisiert wurde, lese ich alle Informationen aus Ihr aus und generiere so mein Objekt DataBase(Die Text Datei enthält Informationen über eine aktuelle Playlist).

Nachdem ich nun das neue Objekt erstellt habe, möchte ich dieses an einen zweiten Thread übergeben der für die Darstellung, sprich das Gui verantwortlich ist.

Mein Grundgedanke war eben, beide Funktionalitäten unabhängig in einem separaten Thread zu betreiben.
Jetzt ist halt die Frage wie kommt mein Objekt vom Typ DataBase vom Thread 1 in Thread 2 damit das Gui angepasst werden kann.

Gruß Andi

 

[rme]

Dazu brauchst du eigentlich keine Threads. Wenn du Swing benutzt, läuft die GUI sowieso in einem eigenen Thread, ohne dass du das bemerkst. Dein Hauptprogramm kann also die GUI erzeugen und danach einfach weiterlaufen bzw. in die Schleife zur Überwachung der Datei wechseln. Sobald die GUI sich ändern soll, benutzt du SwingUtilities.invokeLater, um einen Code-Abschnitt innerhalb des GUI-Threads ausführen zu können. Dein Hauptprogramm wird dadurch nicht blockiert, da es Swing nur bittet, irgendwann bitte den übergebenen Code auszuführen. Das wird sehr bald darauf automatisch passieren und der Code innerhalb des an invokeLater übergebenen Runnables darf auf die GUI zugreifen.

Ungefähr so:

GUI gui = new GUI(); 
gui.setVisible(true);
while(true) {
 // überwache Datei auf Änderungen
 ...
 final DataBase data = new DataBase(...);
 SwingUtilities.invokeLater(new Runnable() {
   public void run() {
     gui.newData(data);
   }
  });
}

 

[Andreas1989]

Das sieht schon deutlich einfacher und effektiver aus

Werd ich dann mal umbauen.

Danke für den Tipp!