SIMON

Welche Simon Version benutzt du denn?

Version 1.1.2

Alles klar. Ich schau dass ich mir's morgen im Detail anschaue. Da für morgen aber schon jede Menge ansteht, kann ich dir nicht versprechen dass ich morgen gleich die Lösung hab.

Aktuell sieht's aber danach aus, als wäre das ein Bug in der SIMON Implementierung.

Gruß
Alex

Mir ist aufgefallen, dass das nichts mit der List selbst zu tun hat. Es reicht schon, wenn überhaupt das Client-Objekt an den Server übergeben wird.
Also wenn ich den Inhalt der beiden Server-Methoden "register" und "unregister" auskommentiere, tritt der Fehler trotzdem auf.

Vielleicht hilft dir diese Info bei der Suche.

So, Fehler gefunden...

deine Register-Methode gibt den Server zurück. Und das ist das Problem:

1) Der Client hat schon eine Server instanz. Durch "register" braucht er nicht nochmal eine
2) Wenn ein Objekt, das mit "SimonRemote" annotiert ist das Netzwerk passiert (beim aufruf oder als Rückgabewert), dann wird es als als Callback-Objekt in der LookupTable von Simon abgelegt. Da du den Server aber schon mit "bind" in der Registry, und somit in der internen LookupTable abgelegt hast, du jetzt aber nochmal versuchst den Serverimplizit als CallbackObjekt in der Registry bekannt zu machen, knallt's bei weiteren Lookup-Versuchen im Server.

Zur Problemlösung:

In IServer:

Mach aus

1public IServer register(IClient client);

einfach

1public void register(IClient client);

Dann klappts.
Gibts denn einen speziellen Grund warum du das so implementiert hattest?

Nichts desto trotz muss ich in SIMON da nachbessern und eine etwas brauchbarere Meldung rausgeben.

Gruß und schönes Wochenende ...
Alex

P.S. Ein wenig Hintergrundinfo:

Mit deiner Implementierung kann sich der erste Client einloggen und ruft "register" auf. Als Antwort kommt das Serverobjekt zurück. Das wird dann als Callback-Objekt zum CLient geschickt. Dafür muss es aber in der Lookuptable registriert werden. Habs noch nicht bis aufs Detail runtergebrochen, aber es sieht so als als ob beim Disconnect des ersten Clients das Objekt aus der Lookup-Table gelöscht wird. Dabei werden auch die in der Table bekannt gemachten Methoden entfernt. Der Zweite Client kommt dann und loggt sich sein. Das via "bind" registrierte Server-Objekt ist noch in der Table, aber keine Methoden mehr. Beim ersten Aufruf (server.getId()) fällt der Server dann auf die Nase. Denn er versucht die Methode auf dem Serverobjekt ausfindig zu machen. Da in der Table aber die Methode entfernt wurde, geht hier der Aufruf gehörig schief.

Werde zusehen dass ich einen Check einbaue dass man ein mit "bind()" registriertes Objekt nicht nochmal als Callback dem Client geben kann.

Ahh, cool. Es funktioniert.

Es gibt keinen speziellen Grund. Ich wollt einfach mal "Simon" kennen lernen, und hab aus Unwissenheit das Server-Objekt zurückgegeben.

Vielen Dank für die Hilfe / Info.

Ein Problem hab ich noch auf der Seite des Clients. Wenn sich mindestens 3 Clients am Server anmelden, und einer von denen beendet die Verbindung, dann schmeisst der betroffene Client manchmal eine Exception:

de.root1.simon.exceptions.LookupFailedException: remoteobject with name [[com.client.Client|ip=localhost/127.0.0.1:1234;sessionID=2;remoteObjectHash=1223313598]] not found in lookup table.
at de.root1.simon.LookupTable.getRemoteObjectContainer(LookupTable.java:180)
at de.root1.simon.ProcessMessageRunnable.processEquals(ProcessMessageRunnable.java:602)
at de.root1.simon.ProcessMessageRunnable.run(ProcessMessageRunnable.java:130)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
de.root1.simon.exceptions.LookupFailedException: remoteobject with name [[com.client.Client|ip=localhost/127.0.0.1:1234;sessionID=2;remoteObjectHash=778152199]] not found in lookup table.
at de.root1.simon.LookupTable.getRemoteObjectContainer(LookupTable.java:180)
at de.root1.simon.ProcessMessageRunnable.processEquals(ProcessMessageRunnable.java:602)
at de.root1.simon.ProcessMessageRunnable.run(ProcessMessageRunnable.java:130)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Woran könnte das liegen?

Ich hab mal die List gegen eine Map<Integer, IClient> getauscht, die getID() Methode entfernt, die register(IClient) Methode gibt jetzt die id als int zurück und die unregister(IClient) in unregister(int id) geändert.
Es ist also nicht mehr nötig bei der unregister das IClient Objekt zu übergeben, um diesen aus der Liste des Servers zu entfernen.

Auf diese Weise klappt alles erheblich besser. Das einzige Problem ist nur noch, dass wenn ich ab und zu die Verbindung trenne, lässt sich das Programm nicht mehr stoppen. Auch das Betätigen des Stopp-Buttons in eclipse bringt nichts, obwohl es als "terminated" angezeigt wird. Erst wenn ich den Server stoppe, lässt sich der Client auch stoppen. Das kommt allerdings selten vor. Bisher trat es nur auf, wenn der betroffene client viele Nachrichten hintereinander versendet hat und anschließend beendet werden sollte. Was könnte das nun sein?
Ich dachte an ein DeadLock, aber dann müsste der Stopp-Button von eclipse funktionieren.

Und dann stellt sich mir noch die Frage, wieso die andere (alte) Methode (also unregister(IClient)) nicht funktioniert?

Woran könnte das liegen?

Die Fehlermeldung besagt, dass er ein Client-Callback-Objekt nicht in seiner Liste mit bekannten Remote-Objekten gefunden hat. Das ganze wurde ausgelöst durch den aufruf der "equals" Methode des Callback-Objekts.

Auf diese Weise klappt alles erheblich besser.

Das hört sich alles etwas "strange" an. Hast du mal im Wiki dir das Session-Pattern angeschaut? Ich denke das ist das was du suchst...
Beim Register ein ClientCallback übergeben, und beim Unregister nochmal übergeben hat zur Folge, dass das Objekt (mit der aktuellen Implementierung) zweimal als Callback-Objekt registriert wird. Das bringt SIMON (noch) etwas durcheinander (siehe auch: http://dev.root1.de/issues/102). Entweder ich verbiete das doppelte übertragen und somit auch registrieren eines Objekts, oder ich schaff's dass SIMON das erkennt und das Objekt nicht erneut registriert. Letzteres wäre wohl Entwickler-Freundlicher.

Das einzige Problem ist nur noch, dass wenn ich ab und zu die Verbindung trenne, lässt sich das Programm nicht mehr stoppen.

Puuh. Das wird immer mysteriöser. Wär's möglich dass du nochmal den Source postest? Gerne kannst du auch dein Eclipse-Projekt zippen und hier anhängen. Wenn du den Code nicht öffentlich publizieren möchtest, kannst du ihn mit auch getrennt per Email zukommen lassen --> alex[at]root1.de

Und dann stellt sich mir noch die Frage, wieso die andere (alte) Methode (also unregister(IClient)) nicht funktioniert?

Eben wegen dem doppelten Übergang des Callback-Objekts. Wird ein Objekt, das mit "SimonRemote" annotiert ist, oder "SimonRemote" implementiert als Methodenargument, oder Methoden-Rückgabewert benutzt, dann wird an der Übergangsstelle das Objekt als ein Remote-Objekt in der internen Lookup-Table gelistet. Der Empfänger des Objekts bekommt nicht das Objekt serialisiert, sondern bekommt nur ein Proxy-Objekt. Alle Aufrufe an dieses Proxy-Objekt gehen an den tatsächlichen Objekteigentümer (via Netzwerk). Der Objekteigentümer sucht beim eingehen eines Remote-Calls das passende Objekt in der Lookup Table. Und dein Stacktrace sagt dir: Das gesuchte Objekt gibt's nicht mehr.

Wie ich oben schon schrieb: Schau dir im Wiki bitte mal das Session-Pattern an...

Gruß Alex

Ok, dass mit dem übergeben von "Callback-Objekten" hab ich jetzt verstanden. Komisch ist nur, dass der Fehler nicht immer auftritt. Deswegen war ich ein bisschen irritiert.

Und zum anderen Problem... Ich habs einfach mal wieder versucht zu rekonstruieren. Also einfach ist es nicht :-P
Aber ich habs geschafft. Wenn ich nun unter Debug mir die laufenden Threads anschaue, dann steht bei dem zu beendenden Prozess folgendes:

Client [Java Application]
<terminated>com.client.Client at localhost:58363
C:\Program Files\Java\jdk1.6.0_23\bin\javaw.exe (19.09.2011 14:26:05)


Also die com.client.Client wird beendet, und der Server macht auch ein unregister, aber javaw.exe läuft weiterhin.

Die anderen Clients funktionieren weiterhin (können also Chatten). Nur sobald die sich dann auch versuchen abzumelden, fangen die auch an zu spinnen. Erst nach etwa 30 Sekunden werden die beendet.

<terminated>Client [Java Application]
<terminated>com.client.Client at localhost:58350
<terminated, exit value: 0>C:\Program Files\Java\jdk1.6.0_23\bin\javaw.exe (19.09.2011 14:26:03)


Hier der überarbeitete Sourcecode:

IServer:

 1package com.server;
 2
 3import com.client.IClient;
 4
 5public interface IServer {
 6  public int register(IClient client);
 7
 8  public void unregister(int id);
 9
10  public void sendMsg(String msg);
11}

IClient:

1package com.client;
2
3public interface IClient {
4  public void rcvMsg(String msg);
5}

Server:

 1package com.server;
 2
 3import java.util.HashMap;
 4import java.util.Map;
 5
 6import com.client.IClient;
 7
 8import de.root1.simon.Registry;
 9import de.root1.simon.Simon;
10import de.root1.simon.annotation.SimonRemote;
11
12@SimonRemote(value = { IServer.class })
13public class Server implements IServer {
14  private static final long serialVersionUID = 7452225439523693867L;
15  private int id = 0;
16  private Map<Integer, IClient> list = new HashMap<Integer, IClient>();
17
18  private int getID() {
19    return id++;
20  }
21
22  @Override
23  public void sendMsg(String msg) {
24    synchronized (list) {
25      for (IClient c : list.values())
26        c.rcvMsg(msg);
27    }
28  }
29
30  @Override
31  public int register(IClient client) {
32    synchronized (list) {
33      int id = getID();
34      list.put(id, client);
35
36      return id;
37    }
38  }
39
40  @Override
41  public void unregister(int id) {
42    synchronized (list) {
43      list.remove(id);
44      System.out.println(list.size());
45    }
46  }
47
48  public static void main(String[] args) {
49    try {
50      System.out.println("Starting Server");
51      Registry registry = Simon.createRegistry(1234);
52      registry.bind("Chatten", new Server());
53      System.out.println("Server started");
54    } catch (Exception e) {
55      e.printStackTrace();
56    }
57  }
58}

Client:

 1package com.client;
 2
 3import java.io.BufferedReader;
 4import java.io.IOException;
 5import java.io.InputStreamReader;
 6import java.net.UnknownHostException;
 7
 8import com.server.IServer;
 9
10import de.root1.simon.Lookup;
11import de.root1.simon.Simon;
12import de.root1.simon.annotation.SimonRemote;
13import de.root1.simon.exceptions.EstablishConnectionFailed;
14import de.root1.simon.exceptions.LookupFailedException;
15import de.root1.simon.exceptions.SimonRemoteException;
16
17@SimonRemote(IClient.class)
18public class Client implements IClient {
19    private static final long serialVersionUID = 2998209260747961462L;
20    private final int id;
21
22    public Client(IServer server) {
23        String msg = "";
24        InputStreamReader converter = new InputStreamReader(System.in);
25        BufferedReader in = new BufferedReader(converter);
26
27        id = server.register(this);
28
29        while (true) {
30            try {
31                msg = in.readLine();
32            } catch (IOException e) {
33                e.printStackTrace();
34            }
35            if ("quit".equals(msg))
36                break;
37
38            server.sendMsg(id + ": " + msg);
39        }
40
41        server.unregister(id);
42    }
43
44    @Override
45    public void rcvMsg(String msg) {
46        System.out.println(msg);
47    }
48
49    public static void main(String[] args) throws SimonRemoteException,
50            IOException, EstablishConnectionFailed, LookupFailedException {
51        try {
52            System.out.println("Connecting...");
53
54            Lookup nameLookup = Simon.createNameLookup("localhost", 1234);
55            IServer server = (IServer) nameLookup.lookup("Chatten");
56
57            System.out.println("Connected");
58
59            new Client(server);
60
61            nameLookup.release(server);
62            System.out.println("Disconnected");
63        } catch (UnknownHostException e1) {
64            e1.printStackTrace();
65        } catch (LookupFailedException e) {
66            e.printStackTrace();
67        } catch (EstablishConnectionFailed e) {
68            e.printStackTrace();
69        }
70    }
71}

Ich hab mal am Ende der main-Methode in der Client-Klasse ein "System.exit(0);" drangehängt. Trotzdem tritt das Problem auf.

Falls du das nachstellen willst, ich starte in eclipse den Client etwa sechs mal. Dann verschicke ich sehr schnell etwa 40 Nachrichten von einem Client an die Anderen und beende ihn mit der eingabe "quit".
Es passiert nicht immer, dass der so komisch abstürtzt. Mein Erfolg den zum absturtzt zu bekommen liegt bei ca. 1:10.

Komischerweise kann ich das Problem nicht mit einer For-Schleife rekonstruieren. Es muss die Eingabe über die Konsole gemacht werden.

Könnte es sein, dass das Problem durch die Konsole in eclipse zustande kommt? Weil als ich aus dem Client-Projekt eine jar gemacht habe, und diese in der Eingabeaufforderung gestartet habe, konnte ich den Fehler nicht rekonstruieren. Zumindest bis jetzt nicht.

Hmm, ich komm nicht ganz mit. Hab deine Implementierung mal in ein Netbeans-Projekt gesteckt und laufen lassen. 1 Server und 6 Clients.
Client #1 sendet schnell nacheinander rund 40 Nachrichten ("1", gefolgt von [Return]), danach sende ich ein "quit" ("quit", gefolgt von [Return]). Gibt bei mir keine Probleme und der Client terminiert auch binnen 1sek komplett (Windows 7 64bit, Java 1.6 Update 24 32bit, Netbeans 7.0.1).

Wenn ich es nun schaffe in diese 1:10 Chance reinzukommen, was genau sollte ich dann sehen?!

Aus deinem vorherigen Post:

Aber ich habs geschafft. Wenn ich nun unter Debug mir die laufenden Threads anschaue, dann steht bei dem zu beendenden Prozess folgendes:

Client [Java Application]
<terminated>com.client.Client at localhost:58363
C:\Program Files\Java\jdk1.6.0_23\bin\javaw.exe (19.09.2011 14:26:05)

Also die com.client.Client wird beendet, und der Server macht auch ein unregister, aber javaw.exe läuft weiterhin.

Na wenn kein Java-Thread mehr am leben ist, dann ist der Java-Programmcode auch schon fertig mit ausführen. Ergo: Kein Simon und keine Testanwendung ist mehr aktiv. Wenn der javaw.exe Prozess der Java-Anwendung aber noch nicht terminiert ist, dann ist die JVM noch nicht fertig mit runterfahren. Evtl. gilt es nocho Resourcen wie Sockets oder dergleichen abzubauen. Das Verhalten kann sich von Windows XP zu Windows Vista / Windows 7 und vor allem zu LInux Systemen unterscheiden. Evtl. pfuscht auch ein Virenscanner mit rein (ja, manche Virenscanner hängen sich an Socketverbindungen ran. Sehr abstrus, aber alles schon da gewesen).

Hast du mal mit dem Taskmanager nachgeschaut ob das Terminieren nach dem eigentlichen Programmende wirklich so lange dauert? Eventuell auch mal den "Sysinternals Process Explorer" (google) statt den TaskManage benutzen. Mit dem tool "tcpview" (ebenfalls google) kannst du live die Socketverwendung einsehen. Evtl. dauert es einfach bis das OS den Socket wieder freigibt und dann erst der Prozess terminiert werden kann.
Im normalfall sollte das alles super zügig von statten gehen. Aber in manchen Konfig/Softwarekonstellationen ist das anders. Also mal versuchen Firewallprogramme und Virenscanner abzuschalten. Dummerweise sind nicht alle abgeschalteten Programme auch wirklich deaktiviert. Hatte hier schon einen User mit einer Software die man erst mit einer Deinstallation zum schweigen brachte. Also auch das mal probieren.

Gruß
Alex

Das Problem tritt nur auf, wenn ich die Konsole in eclipse verwende. Von daher, denke ich mal, kann man das Problem getrost vernachlässigen.
Es ist so, dass zwar der Java-Thread beendet wird, aber nicht die javaw. Auch nach einer Stunde kann ich in eclipse weiterhin den stop-button drücken, und der Prozess läuft weiter.
Ob jetzt aber noch eine Socketverbindung da ist, weiss ich nicht. Das kann ich ja bei gelegenheit auch mal testen.

Auf jeden Fall sieht für mich das Ganze nach einem Bug in eclipse selber aus. Immerhin kann ich nur in eclipse dieses Problem rekonstruieren. Starte ich die Java-Anwendung direkt in der Eingabeaufforderung, gibt es keine Probleme. Der javaw-Prozess wird immer beendet.

Danke für deine Hilfe!!!

Hmm, okay. Das würde erklären warum ich mit Netbeans das Problem erst gar nicht nachstellen kann.
Die Eclipse-Console ist eh ein wenig mit vorsicht zu genießen. Hab die Erfahrung gemacht dass Ausgaben auf der Console verzögert, oder im schlimmsten Fall in der falschen Reihenfolge erscheinen.
Welche Eclipse Version benutzt du denn?

Gruß
Alex

Eclipse Java EE IDE for Web Developers.

Version: Helios Service Release 1
Build id: 20100917-0705