Stream Ende erkennen

deetee

Hallo,

ich bekomme Daten von einem socket und verarbeite diese in einem BufferedReader Stream, hier reader.

Doch wieso erkennt mein code das Stream Ende nicht richtig? Die Daten werden KOMPLETT übertragen und dann blockiert read() einfach. Ich krieg keine IO Exception und kein -1 zurück.

try {
				int len;
				while(true) {
					len = reader.read(b);
					if(len == -1)
						break;
					else {
						readInputStreamBlock = String.valueOf(b, 0, len);
						requestMessage.append(b, 0, len);
					}
				}
				}catch (IOException e) {
					LOG.error("111Open error " + e);
				}

EDIT:
Korrektur: Di e-1 wird zurückgegeben, allerdings erst, nachdem der Socket nach einer gewissen Zeitspanne geschlossen wurde. Muss ich beim client den Socket schließen, nachdem alle Daten verschickt wurden, damit auf dem Server die read() richtig arbeiten kann?

Ajaw

So funktioniert das auch nicht. Die Abbruchbedingung deiner Schleife sollte sein, dass reader.read() null zurück liefert.

So wie du es gemacht hast ist es eigentlich eine Endlosschleife, denn wie du ja bereits gemerkt hast wird keine IOException geworfen wenn keine Daten zum lesen vorliegen, sondern read wartet einfach.

deetee

es ist ne pseudo endlosschleife, denn ich hab ne Aussteigsbedingung definiert indem ich das -1 abfrage.

Momentan siehts danach aus, dass der Server den neuen Thread je client in einer blockierenden Methode erstellt. Somit nur ein client gleichzeitig bedient werden kann. Und dieses Blockieren scheint auch irgendwie mit dem Problem zu tun zu haben.

DEvent

Wieso laesst du nicht ein "EndOfData" schicken, wenn der Server keine weiteren Daten mehr senden will und der Socket geschlossen werden kann?

So wuerde ich es machen, denn den Socken einfach so zu schliessen waere IMHO ein Fehlerfall und ansonsten kann der Client gar nicht wissen, wann die Daten zu Ende sind.

deetee

Ja stimmt schon, der Socket darf erst geschlossen werden, wenn alle Seiten die Kommunikation abgeschlossen haben, logisch. Ich hatte nur die Socket Programmierung unter Unix mit Prozessen im Kopf, da muss der Client Socket vom Server Parent Prozess geschlossen werden, nachdem der Deskriptor an den Child Prozess weitergereicht wurde. Da sonst die Verbindung zweimal existiert, was in Java ja nicht der Fall ist, wofür glaube ich die Speicherverwaltung von threads verantwortlich ist.

Ein EndOfData wäre dann eine Abhängigkeit beim Client, und das darf nciht sein. Der Client soll nur eine Verbindung auf einen bestimmten Port herstellen und SOAP Daten verschicken. Das wars. Keine zusätzlichen Bedingungen an den Client.

Aktuell sieht es so aus, dass der Server Parent nach accept() bei der Threaderzeugung nochmal in einer blockierenden Methode ist (ist ein Packet von org.apache.*) und da erst nach dem timeout wieder rauskommt und den nächsten client annehmen kann. Das scheint wohl das Hauptproblem grad zu sein. Muss man mal sehen, ob alles funktioniert, wenn das behoben ist.