ServerSocket wirft nicht immer eine BindException

[VfL_Freak]

Erstmal Hallo an alle User :toll:

Da ich hier neu und noch nicht mit allen Feinheiten vertraut bin, bitte ich darum, mich auf die Dinge hinweisen, die u. U. durch Unwissenheit falsch mache - Danke

Zu meinem Problem: in der Anwendung, die ich vor einiger Zeit übernommen habe, wird ziemlich zu Beginn ein neuer ServerSocket mit einem fix definierten Port angelegt. Dies soll verhindern, die auf dem gleichen PC eine zweite Instanz gestartet werden kann, da ja eigentlich beim zweiten Start mit dem gleiche Port eine BindException geworfen wird ...

Hier der relevante Code:

protected ServerSocket listenerSocket = null;
...
private void checkMultiWorkers()
{
    // Mutexserverport zur Instanzenkontrolle des Workers
    // ist im Original in einer Config-Datei deklariert!!
    public static final int nMutexServerport = 62987;
    try 
    {
        listenerSocket = new ServerSocket( nMutexServerport );
    }
    catch( Exception ex ) 
    {
        ex.printStackTrace( );
    	JOptionPane.showMessageDialog( this,
                                "Es ist bereits eine Programminstanz auf diesem System aktiv.\n" +
                                "Sollte dies nicht der Fall sein, bitte den Rechner neu starten !",
                                "Fehler", JOptionPane.ERROR_MESSAGE, null );
    	System.exit( -2 );
    }
} // checkMultiWorkers

Es ist in den letzten Monaten mehrfach aufgefallen, dass die erwartete BindException auf einzelnen PCs nicht geworfen wird!
Die Rechner laufen mittlerweile allesamt unter Java6 und (derzeit noch) XP Prof.

Hat irgendjemand eine Idee, woran dies liegen kann resp. wie ich ggf. sonst den Start einer zweiten Instanz verhindern kann?

Danke im voraus :applaus:

Gruß
Klaus

 

[faetzminator]

Überprüf ServerSocket (Java Platform SE 6), da dürfte dann nicht zwei Mal das gleiche rauskommen.
Anmerkung: Klassen schreibt man Camel Case mit beginnendem Grossbuchstaben.

 

[VfL_Freak]

Moin,

Überprüf ServerSocket (Java Platform SE 6), da dürfte dann nicht zwei Mal das gleiche rauskommen.

erstmal Danke für den Tipp - das werde ich ausprobieren - und dann hier das Ergebnis berichten

Anmerkung: Klassen schreibt man Camel Case mit beginnendem Grossbuchstaben.

Aha - und beim welcher Klasse in meinem Code-Schnipsel habe ich es nicht gemacht ???:L

Gruß
Klaus

 

[VfL_Freak]

Moin,

hmm, scheint so, als wenn mich das auch nicht wirklich bringt ... ;(

Mal davon abgesehen, dass ich hier auf meinen beiden Entwicklungs-PCs stets die Exception bekomme, wird ja mit der genannten Methode auch wohl immer die zuvor verwendete Portnummer zurückgegeben.

Ich verstehe nicht, was mir der Aufruf wirklich bringen sollte für den Fall, dass die bindException NICHT geworfen wird ...

Allerdings bin ich eben bei einer Websuche auf diesen Beitrag gestossen:
http://www.java-forum.org/java-basi...atei-problem-programm-nur-einmal-starten.html

Werde mal versuchen, mich daran lang zu hangeln ...

Gruß
Klaus

 

[faetzminator]

Aha - und beim welcher Klasse in meinem Code-Schnipsel habe ich es nicht gemacht ???:L

Ups, hab nichts gesagt

Zu deinem Problem: es kann grundsätzlich nicht sein, dass zwei Mal auf dem gleichen Port gehört wird. Wenn die beiden Ports gleich sind, gehe ich davon aus, dass der erste ServerSocket sich irgendwie schliesst (bzw. geschlossen wird). Wenn diese aber unterschiedlich sind, würde aus irgendeinem unerfindlichem Grund der zweite Socket auf einem anderen Port hören, weil der erste schon besetzt ist. Verwendest du überall die JRE von Sun?

 

[VfL_Freak]

Guten Morgen,

ja, das wird auf allen relevanten PCs verwendet (Versionen schwanken wohl leicht; auf jeden Fall überall Java6 zwischen SubV11 und 20).
Betroffen sind - wie gesagt - scheinbar nicht alle, sondern nur einzelne Rechner ... auch die Frage, ob sie intern oder extern angebunden sind, scheint unerheblich zu sein!

Was mich auch leicht wundert, dass ich immer eine BindException bekomme, während in allen Beispielen mit ServerSocket (und auch der API) immer nur von IOException die Rede ist ...

java.net.BindException: Address already in use: JVM_Bind
	at java.net.PlainSocketImpl.socketBind(Native Method)
	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
	at java.net.ServerSocket.bind(ServerSocket.java:319)
	at java.net.ServerSocket.<init>(ServerSocket.java:185)
	at java.net.ServerSocket.<init>(ServerSocket.java:97)
	at com.gselectronic.worker.mainFrm.checkMultiWorkers(mainFrm.java:9783)
	at com.gselectronic.worker.mainFrm.jbInit(mainFrm.java:8100)
	at com.gselectronic.worker.mainFrm.<init>(mainFrm.java:7932)
	at worker.mainApp.<init>(mainApp.java:85)
	at worker.mainApp.main(mainApp.java:150)

Hatte eben nochmal sein bisschen rumgetestet und spannenderweise feststellen müssen, dass es augenscheinlich einen Unterschied macht, ob ich die SocketServer-Variable lokal in der Funktion oder globaler außerhalb deklariere.
Bei der lokalen Version (siehe mein erster Post - dann allerdings OHNE das protected (war ein Übertragungsfehler)) kommt bei mir hier die Exception auch nicht und es wird mit "getLocalPort" jeweils die fix in der Config deklarierte Portnummer angezeigt :autsch:

Gruß
Klaus

 

[faetzminator]

Öhm ja, du musst natürlich den ServerSocket irgendwo halten Ansonsten wird wohl der Socket irgendwann geschlossen (weil der GC anläuft).

 

[VfL_Freak]

Moin,

Hast Recht .... logisch ... ist wohl noch zu früh (nach der Feierrei :lol

Deswegen ist der ServerSocket dateiglobal in meiner Hauptklasse drin und somit gesetzt, solange die Anwendung läuft !

Verstehe nur weiterhin nicht, warum die Exception mal kommt und mal nicht ;(

Gruß
Klaus

 

[faetzminator]

Deswegen ist der ServerSocket dateiglobal in meiner Hauptklasse drin und somit gesetzt, solange die Anwendung läuft !

Whatever dateiglobal means...
Ist die Deklaration statisch? Ansonsten kann natürlich wieder der GC kommen, wenn es eine Instanzvariable ist und diese Instanz irgendwann nicht mehr referenziert wird

 

[VfL_Freak]

Whatever dateiglobal means...

in diesem Fall svw. "Klassenelement" feif:

Ist die Deklaration statisch?
Ansonsten kann natürlich wieder der GC kommen, wenn es eine Instanzvariable ist und diese Instanz irgendwann nicht mehr referenziert wird

Nein, bislang nicht!
Aber IMHO dürfte der GC die Instanz doch erst dann wegkegeln, wenn das Objekt der Klasse selbst beendet wird, oder etwa nicht??

Gruß
Klaus

 

[FArt]

in diesem Fall svw. "Klassenelement" feif:


Nein, bislang nicht!
Aber IMHO dürfte der GC die Instanz doch erst dann wegkegeln, wenn das Objekt der Klasse selbst beendet wird, oder etwa nicht??

Gruß
Klaus

Was auch immer "wenn das Objekt der Klasse selbst beendet wird" heißt... wenn ein Objekt nicht mehr referenziert wird, kann es vom GC gelöscht werden. Es muss dazu nicht explizit beendet werden.

 

[VfL_Freak]

Moin,

Was auch immer "wenn das Objekt der Klasse selbst beendet wird" heißt...
wenn ein Objekt nicht mehr referenziert wird, kann es vom GC gelöscht werden. Es muss dazu nicht explizit beendet werden

ist wohl heute nicht mein Tag ... ueh:
Ich meinte schon "das es nicht mehr referenziert wird" ....

Wir reden hier von der Haupt-Klasse der Anwendung, deren Objekt (nach einem splashFrm) in der mainApp instantiiert wird!

Der erwähnte listenerSocket wird dort nur instantiiert und dann nicht weiter beachtet .... IMHO doch also erst bei Schließen des Objekts durch den GC beendet, oder wie ???:L

Gruß
Klaus

 

[FArt]

Moin,


ist wohl heute nicht mein Tag ... ueh:
Ich meinte schon "das es nicht mehr referenziert wird" ....

Wir reden hier von der Haupt-Klasse der Anwendung, deren Objekt (nach einem splashFrm) in der mainApp instantiiert wird!

Der erwähnte listenerSocket wird dort nur instantiiert und dann nicht weiter beachtet .... IMHO doch also erst bei Schließen des Objekts durch den GC beendet, oder wie ???:L

Gruß
Klaus

Du meinst mit schließen des Objekts vermutlich die close-Methode des SocketServer.
Ja, genau das kann ein Problem darstellen. Man sollte darauf achten, dass man die verwendeten Ressourcen sauber explizit schließt. Wird das Objekt nicht mehr referenziert, kann es vom GC gelöscht werden. Hält die VM aber über das Objekt Systemressourcen (z.B. Sockets), dann werden diese nicht unbedingt automatisch freigegeben, was dann zu weiteren Problemen führen könnte. Manche Objekte machen ein "close falls noch nicht geschehen" in der finalize-Methode... aber auch das hat wieder andere Nachteile, nicht zuletzt weil man nicht sagen kann ob und wann diese von der VM aufgerufen wird.

 

[VfL_Freak]

Du meinst mit schließen des Objekts vermutlich die close-Methode des SocketServer.

Nein, das passiert nicht! Der erwähnte listenerSocket wird nur wie beschrieben instantiiert - mehr nicht!

Ich meine das Beenden der Haupt-Klasse der Anwendung!
Durch das Anklicken des Beenden-Button werde noch div. Aktionen ausgeführt (etliche laufende Timer beendet etc.) und dann die gesamte Anwendung beendet. Erst hierbei dürfte doch der GC die Instanz des ServerSockets beenden!

Und selbst, wenn dieses Freigeben nicht sauber funzen würde, hätte ich doch allenfalls das Problem, dass anschließend die Anwendung nicht erneut gestartet werde könnte, weil ggf. der Port noch blockiert, oder stehe ich jetzt völlig auf dem Schlauch ??

Gruß
Klaus

 

[FArt]

Nein, stimmt schon.
Wenn nur die Hauptklasse beendet wird und alle Daemon-Threads der VM, dann beendet sich die VM. Sytemressourcen können systemabhängig (sofern sie nicht korrekt explizit geschlossen wurden) noch eine Zeit lang belegt bleiben. Sockets nehmen z.B. gerne mal den Status TIME_WAIT ein. In der Zeit ist der Socket immer noch nicht für neue Anfragen frei, obwohl der Prozess schon nicht mehr existiert.

 

[VfL_Freak]

Ja, eben ....

Allerdings löst diese Erkenntnis leider nicht das Problem, dass die bewußte Exception manchmal nicht wie erwartet auftritt und die Applikation dann ein weiteres Mal startet !

Ich denke auch nicht, dass es damit zu tun hat, ob der betroffene PC intern oder extern ans Firmennetz angebunden ist!
Ebenso würde ich mal den erst vor einigen Monaten erfolgten Umstieg von Java1.4 über 1.5 auf 1.6 dafür verantwortlich machen (zumindest wenn die APIs vergleiche)!

Nach Aussage der Mitarbeiter konnte man angeblich an einzelnen Arbeitsplätzen die Applikation schon immer mehrfach aufrufen, an anderen angeblich nie ..... ;(???:L
Bin wie gesagt derzeit ziemlich ratlos :shock:

Gruß
Klaus

 

[faetzminator]

Wie gesagt, lass dir die Portnummern loggen, evtl. auch alle Aufrufe auf dem ServerSocket (vor Allem close()).

 

[VfL_Freak]

ja, das mache ich ja inzwischen auch ... nur :
entweder kommt die Exception und die zweite Applikation wird wieder beendet
oder ich sehe halt in der Konsole rsp. im Logfile jeweils die gleiche fixe Portnummer!

Wie gesagt: mit diesem ServerSocket wird nichts weiter gemacht - auch kein close() !
Es gibt nur diesen eine Stelle "listenerSocket = new ServerSocket( nMutexServerport );" ... :bahnhof:

Gruß
Klaus

 

[FArt]

Obiger Code ist nichtssagend.

Faetzminator hat eigentlich schon alles gesagt. Ich wiederhole es vielleicht noch mal.

Die Sache mit dem ServerSocket ist wasserdicht. Wenn eine Instanz davon für Port x existiert, geht das nicht mit einer zweiten. Wenn es mal funktioniert, mal nicht, heißt das, dass die Instanz nicht mehr existiert.

Tipp: die erste Instanz startet einen Thread, der den ServerSocket macht und mit accept auf eingehende Verbindungen wartet. Der nächste wird das nicht mehr machen können.

Es gibt hier im Forum schon viele Lösungen zu dem Problem. Mit java .nio und gelockten Files und Heartbeat, mit Sockets, kombiniert usw.
Im Internet gibt es auch schon fertige Lösungen. Google anwerfen hilft da.

 

[Geeeee]

Irgendwie ist diese zweite Seite etwas verwirrend. Falls meine Antwort gerade schon genannt wurde (kommt mir nicht so vor), dann beachtet mich einfach nicht Die Anmerkungen über den GC und keine Referenz beachte ich hierbei.
Du rufst deine Funktion [c]private void checkMultiWorkers()[/c] auf, dort wird [c]protected ServerSocket listenerSocket = new ServerSocket( nMutexServerport ); ... [/c] aufgerufen und die Methode ist "fertig". Nach dem Ende greift nun wie schon gesagt wurde der GC und entfernt das Objekt (eventuell oder bald oder nie)
Damit könnte der Socket wieder frei werden.
2 Lösungsansätze:
1. Den listenerSocket als (static) Field deklarieren.
2. Nach dem Öffnen des Sockets in einem Thread auf Connection warten (mit ausreichend sleeps, weil ja nie ne connection kommen sollte und wenn eine kommt mit ihr tun, sondern einfach auf die nächste warten).

Edit: och menno...FArt war schneller

 

[VfL_Freak]

Hallo Geeee,

auch Dir Danke für Deine Mühe!

Du rufst deine Funktion [c]private void checkMultiWorkers()[/c] auf, dort wird [c]protected ServerSocket listenerSocket = new ServerSocket( nMutexServerport ); ... [/c] aufgerufen und die Methode ist "fertig". Nach dem Ende greift nun wie schon gesagt wurde der GC und entfernt das Objekt (eventuell oder bald oder nie)
Damit könnte der Socket wieder frei werden.
2 Lösungsansätze:
1. Den listenerSocket als (static) Field deklarieren.
2. Nach dem Öffnen des Sockets in einem Thread auf Connection warten (mit ausreichend sleeps, weil ja nie ne connection kommen sollte und wenn eine kommt mit ihr tun, sondern einfach auf die nächste warten).

Wie gesagt, ganz so stimmt der Code nicht - das war durch das Zusammenkopieren vor dem Übertragen nach hier passiert (die Original-Datei ist mittlerweile fast 20.000 Zeilen lang .... ;( )
Ich habe die Stelle jetzt im ersten Post mal korrigiert und zudem in der Software auch mal auf static geändert
Von daher ist die Instanz "listenerSocket" während der gesamt Laufzeit vorhanden, das habe ich inzwischen mehrfach im Debugger geprüft (leider tritt der Effekt hier auf meinen beiden Entwicklungs-PCs nur höchst selten auf) und die Anwender-Clients kann ich aus verschiedenen Gründen nicht debuggen!

Na, ich werde mal die Variante mit dem Thread/accept einbauen und dann bei den Live-Anwendern testen lassen, wenngleich mir nicht wirklich klar ist, warum der accept()-Aufruf mein Problem lösen könnte ....

Gruß
Klaus

 

[Geeeee]

Na, ich werde mal die Variante mit dem Thread/accept einbauen und dann bei den Live-Anwendern testen lassen, wenngleich mir nicht wirklich klar ist, warum der accept()-Aufruf mein Problem lösen könnte ....

Das war auf deinen "Ur-Quellcode" bezogen und dann würde das accept (der Mechanismus sollte dann in einem Thread ausgelagert sein) blockieren und auf einen Client warten (wenn wirklich einer kommt, einfach ignorieren).
Damit wäre sichergestellt, dass dein ServerSocket-Objekt nicht wegfliegt, weil du dich ja immer in der o.g. Funktion aufhältst.