Socket.getInputStream().available() blockiert Oberfläche!

[Grizzly]

Ich habe folgendes Problem: Ich programmiere gerade eine Client-Server-Anwendung und realisiere die Netzwerkverbindung über Sockets. Nun habe ich aber folgendes Problem: Ich habe die Behandlung der Netzwerk-Verbindung in eine eigene Thread-Klasse ausgelagert, so dass die Oberfläche des Clients nicht blockiert wird. Alle Zugriffe von der Verbindung auf die Oberfläche sind über javax.swing.SwingUtilities.invokeLater(Runnable doRun) realisiert. Trotzdem blockiert der Empfang der Daten (Siehe Code-Ausschnitt der Thread-Klasse) die Oberfläche.

Zur Erklärung: this.in ist der InputStream des Client-Sockets

	private String readCommand(final boolean interruptible) {
		int data;
		StringBuffer sb = null;
		
		try {
			while (!(this.isInterrupted() && interruptible)) {
				if (this.in.available() > 0) {
					data = this.in.read();
					if (data == '|') {
						break;
					} else if (data != -1) {
						if (sb == null) {
							sb = new StringBuffer();
						}
						sb.append((char) data);
					}
				}
			}
		} catch (IOException ioe) {
			this.println(ioe.getLocalizedMessage());
			return null;
		}
		// Ist der Empfang unterbrochen worden?
		if (this.isInterrupted()) {
			return null;
		}
		// Daten zurueckgeben.
		if (sb == null) {
			return "";
		}
		return sb.toString();
	}

Und zwar steht die Oberfläche ca. alle 10 Sekunden für 2 Sekunden. Wenn ich die Klammer mit this.in.available() entferne, tritt der Effekt nicht auf. Allerdings kann ich dann den Thread mit interrupt() nicht mehr stoppen, da this.in.read() die while-Schleife blockiert, bis Daten eintreffen. Auch das Setzen des Timeout des Sockets hat nichts gebracht, da die Verbindung ja noch besteht, es halt aber nur keine Daten übermittelt werden.

Hattet Ihr schon mal ein ähnliches Problem? Lösung?

 

[Grizzly]

So, hab' jetzt mal versucht um den InputStream einen BufferedInputStream zu legen. Hat aber nix gebracht. :cry:

 

[Grizzly]

Okay, hab' das Problem lösen können. Anscheinend kommt die VM nicht mit der Swing hinterher, wenn man zu oft den Socket behandelt. Lösung: Den Thread, in dem der Socket behandelt wird, mit setPriority(Thread.MIN_PRIORITY) auf die niedrigste Priorität stellen. Ab da funktioniert es.

Das Problem ist bei mir wahrscheinlich bisher nie aufgetreten, da ich nie Netzwerk und Swing gleichzeitig benutzt habe.