Frage zu ServerSocket oder EDT

[hdi]

Hey,

Ja, du hast richtig gelesen: Ich habe ne Verständnisfrage zur Klasse ServerSocket oder zum EDT. Gut dass das nicht komplett verschiedene Dinge sind nicht wahr Dummerweise kann ich nicht mal ausmachen was von beidem hier eigentlich relevant ist... Vllt beides?!

Okay also folgende Zeile:

new ServerSocket(14231, 0, "localhost");

Wirft ne BindException wenn da schon "dicht" gemacht wurde,d.h. diese ServerSocket-Instanz bereits erzeugt wurde. Wird oft im Netz vorgeschlagen als Ansatz für One-Instance-Apps, also Programme die man als User immer nur einmal zur selben Zeit starten kann. Die Idee ist eben dass die zweite Instanz beim Start in die Exception rennt, da die erste Instanz eben den Bind hält.

Nun zu meinem Problem damit:
Ich hatte das schon mal erfolgreich bei einer meiner Apps verwendet. Jetzt wollte ich das für ne andere App wieder verwenden und stellte fest: Es geht nicht ???:L Nach viel Kopfrauchen und Rumprobieren habe ich festgestellt dass es wohl etwas damit zu tun hat wann genau das gemacht wird bzw wie es grad so mit den Threads des Prozesses ausschaut. Und hier kommt der EDT ins Spiel.

Konkret:
Ich hab obige Zeile in meiner main(), gleich am Anfang. Danach wird per invokeLater meine GUI gebaut und angezeigt. Wie sich nun herausgestellt hat: Wenn mein Frame angezeigt wird bevor das Ende der main() erreicht wird, dann funktioniert das. Beim Versuch meine App erneut zu starten fliegt die BindException, alles ok.
Wird das Ende der main() aber erreicht und mein Frame wird noch nicht angezeigt, dann wird der Bind zu diesem Zeitpunkt anscheinend aufgelöst, denn dann funktioniert das nicht und ich kann meine App hundertfach starten. Komisch, denn meine App wird ja in so einem Fall trotzdem nicht komplett beendet, der Code den ich per invokeLater auf den EDT lege wird ja immer ausgeführt, und meine App läuft... Ist ja nicht so, dass das Programm terminiert wenn das Ende der main() erreicht wird aber der Code vom invokeLater noch nicht aus der Queue geholt wurde. Das passiert ja immer.

Aber für diese ServerSocket Geschichte macht das scheinbar nen Unterschied. Also... ka woran liegt das nun. Eigenart von ServerSocket? Oder kapier ich hier generell etwas nicht darüber wie/wann eine App eigentlich feststellt ob sie beim Ender der main() terminieren muss oder irgendein Thread vom EDT läuft/gleich laufen wird??

 

[SlaterB]

hmm, so viel Text und doch eher unverständlich,
ist der new ServerSocket(14231, 0, "localhost");-Aufruf nicht zu Beginn der main() vor dem GUI-Aufruf?
wenn eine Exception fliegt dann muss doch der GUI-Aufruf übersprungen werden?
das solltest du genau klären, ob das Programm beendet wird oder nicht ist gegenüber genauer Kontrolle von Codereihenfolge fast unwichtig

-----

ansonsten:
oder kommt der ServerSocket erst danach/ parallel in einem anderen Thread?
jedenfalls ist das Ende der main() für sich kein besonderes Ereignis, wenn nur ein invokeLater() in der main() steht, dann wird die main() ja auch beendet und die GUI kommt trotzdem..

fange die Exception vom Socket ab und schreibe im catch System.exit(1); dann ist ganz egal ob EDT oder sonstwer was zu melden hat

 

[ice-breaker]

also für mich klingt das Problem eher nach einem Synchronisierungsfehler, 2 Threads die unabhängig laufen aber das nicht gewünscht zu sein scheint.
Ansonsten muss ich mich SlaterB anschließen, viel Text aber trotzdem kann ich es nicht nachvollziehen.

 

[hdi]

Hey,

das ServerSocket Zeugs ist ganz zu Beginn in der main, und ja, natürlich kommt er dann gar nicht zum invokeLater wenn da ne Exception fliegt. Das Problem ist ja eben, dass keine fliegt

Also.. das Problem liegt nicht beim Starten der zweiten Instanz, sondern bei der ersten: Diese löst das Bind wieder auf, sobald das Ende der main() erreicht wird. Aber eben nur, wenn bis dahin noch kein frame angezeigt wird.

jedenfalls ist das Ende der main() für sich kein besonderes Ereignis, wenn nur ein invokeLater() in der main() steht, dann wird die main() ja auch beendet und die GUI kommt trotzdem..

Eben, meine App läuft ja auch! Aber das Bind existiert nicht mehr... Das bleibt nur bestehen wenn eben am Ende der main das Frame sichtbar ist. Kommt dieses erst danach, dann ist der Effekt des ServerSocekt-Aufrufs futsch...

edit: Ich geb euch gleich ein KSKB, mein Text scheint ja eher zu verwirren

 

[SlaterB]

na ehrlicherweise ist es wohl nur schlecht gelesen von mir (uns), bin jetzt eben auch schon zu neuen Erkenntnissen gekommen,

dass der Socket mit Ende der main() möglicherweise wieder freigegeben wird oder dass ganz einfach ungewiss ist, was dann der GarbageCollector oder jemand anders damit macht (und auch wann!), ist für mich eine ganz normale Grundlage,

wenn der Socket fürs ganze Programm offen gehalten werden soll, dann speichere ihn in einer statischen Variable,
so besteht auf ganz einfache Weise weniger Ungewissheit und mehr Verlässlichkeit, egal was am Ende der main() theoretisch passiert,

noch sicherer wirds mit einem kompletten Thread für diese Aufgabe, der regelmäßig überprüft ob der ServerSocket bestehen bleibt,
ihn gegebenfalls neu öffnet, falls sich irgendwie nachvollziehbar ein vorzeitiges Schließen ergibt,
der den User warnt wenn das erneute Öffnen nicht klappt oder schon wenn ein sonstiges ungewöhnliches Ereignis stattfindet

 

[hdi]

@Slater mit dem GC hat das nix zu tun, beim Erstellen einer ServerSocket Instanz werden komplexere Dinge angelegt, die intern auch referenziert bleiben. Ist nicht so dass dieser Bind-Effekt verschwindet wenn diese Instanz gelöscht wird.

Als Beweis gleich mal das KSKB was ich gerade gemacht habe. Wie sooft schlägt der Vorführeffekt zu und bei dem KSKB funzt es einwandrei, egal ob das Frame am ende der main() schon angezeigt wird oder nicht... :autsch: Kann man testen indem man das sleep aus dem invokeLater rausnimmt und vor das Ende der main() klatscht. Egal wie rum, der Bind steht und die App lässt sich nicht zweimal starten:

import java.io.IOException;
import java.net.BindException;
import java.net.InetAddress;
import java.net.ServerSocket;

import javax.swing.JFrame;
import javax.swing.SwingUtilities;

public class ServerSocketDemo {

	public static void main(String[] args) {

		try {
			System.out.println("Erstelle ServerSocket...");
			new ServerSocket(12345, 0, InetAddress.getByName("localhost"));
		} catch (BindException e) {
			System.out.println("----- Eine andere Instanz läuft bereits! EXIT -----");
			System.exit(0);
		} catch (IOException e) {
			e.printStackTrace();
		}

		SwingUtilities.invokeLater(new Runnable() {
			@Override
			public void run() {

				// doing some other stuff...
				try {
					Thread.sleep(1500);
				} catch (InterruptedException e) {
					e.printStackTrace();
				}

				JFrame f = new JFrame("DEMO");
				f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
				f.setSize(100, 100);
				f.setLocationRelativeTo(null);

				System.out.println("Zeige Frame...");
				f.setVisible(true);
			}
		});

		System.out.println("main() endet...");
	}
}

ABER: In meiner App funktioniert das NICHT ???:L Und eig. sieht das bei mir nicht wirklich anders aus, nur dass statt dem Platzhalter-sleep halt echter Code steht. Also irgendwas ist da total strange.. Ich muss mir das jetzt wohl noch genauer ansehen, mir kommt es irgendwie so vor als würde es mehr oder weniger nach Lust und Laune manchmal klappen und manchmal nicht.. Ich meld mich auf jeden Fall wieder, notfalls mit einer abgespeckten Version meiner echten main(), damit ihr seht dass es da eben leider nicht so klappt wie im KSKB..

 

[hdi]

Okay hab das Rätsel gelöst, jetzt haltet euch fest:

Es funktioniert in meiner App nicht, weil ich ein eigenes Look & Feel benutze! Genauer: Es funktioniert nicht, wenn ich das Socket erstelle bevor das L&F geladen wurde. Mache ich es danach, funktioniert es. WTF? Kann mir einer sagen was das L&F mit nem ServerSocket zu tun haben soll? Anscheinend geht das auf irgendwelchen Irrwege durch die VM und überschreibt das irrwitzigste Zeug, zB ServerSockets..

Aber: Das haben wohl die Jungs von pushingpixels verkackt (ich nutze das Substance L&F von denen), denn ich habs grad zB mit Nimbus L&F versucht und da geht es, egal wie rum..

Ist doch echt ein Joke oder...

 

[SlaterB]

Jokes waren auch alle meine Beiträge hier, ich bin eigentlich schlauer

wenn du es bei dir reproduzieren kannst, dann teste doch noch was mit diesen mehreren ServerSockets passiert,
kann der erste noch Verbindungen annehmen oder ist er aus Client-Sicht tot?
kannst du im selben Programm nochmal den Socket öffnen?

was passiert wenn da ein Thread vorher mit accept() gewartet hat/ was passiert wenn du accept() nachher aufrufst,
unter der Annahme dass die den ServerSocket doch ausnahmsweise in einer Variablen merkst,
was liefern isBound()/ isClosed()?

 

[hdi]

@SlaterB dein Post hört sich für mich jetzt so an als wäre es an dir vorbeigegangen, dass sich meine Fragen geklärt haben?! Es funktioniert jetzt alles wie es soll. Jeder weitere Versuch der Instanz-Erzeugung auf den selben Port + Adresse bringen eine BindException.

Inwiefern da jetzt noch ein accept möglich ist oder was irgendwelche Methodenaufrufe returnen weißich nich und is mir auch sooooo egal Oder war das jetzt eine Bitte, das für dich herauszufinden? Du kannst ja das KSKB benutzen, in meiner App hat das zumindest nix verloren jetzt *bestimmt aber dennoch respektvoll weggeh* :bae:

 

[SlaterB]

ohne extra den Look&Feel zu holen kann man das anscheinend nicht selber testen,
wenn du diese Fragen nicht mehr klären willst dann auch ok,

wollte nur noch irgendwas sinnvolles beitragen und in deinem ersten Posting klang es ja schon so als wärst du an allen Details interessiert

 

[hdi]

NAja ich war nur interessiert daran das mit der Bind richtig hinzubekommen. Soviel gibt's da aber nich mehr dran zu testen zwecks L&F. Zumindest so wie ich das sehe, es ist ganz einfach, wenn auch komisch:

1. L&F 2. ServerSocket -> geht
1. ServerSocket 2. L&F -> geht nicht.

Habs paar dutzend male versucht, scheint kein Zufall gewesen zu sein