Birte

• SensorWorldProperties schreiben, Klasse zum versenden von Properties ohne jegliche Referenz (durch klonen und getValue o.Ä.) auf das eigentliche Objekt, jeweils Unterklasse für jede Komponente
• [OK] Vorschlag: im CommonConnector auch die Consumer und Producer in jeweils einer Map vorhalten, analog zu Destinations.
  • Map<Destination, Producer> und dann immer nur getProducer(Destination d) aufrufen und dort entweder Vorhandenen zurückgeben oder neu instanziieren. (hab ich mal so geändert, finde ich auch besser(Birte)
  • Map<Destination, Consumer>, (Methode analog bei der registration() würde ich schon direkt den consumer erzeugen lassen, anstatt den Umweg über das Dictionary zu gehen(Birte))
  • registration von PhenomenonConnector bei der DictionaryControl läuft
  • registration von SensorConnector, CommConnector bei der DictionaryControl, läuft

ant

• Ant Build für mehrere Prozesse, z.B. für Peer {1,2} .java, vielleicht auch mit Maven (http://maven.apache.org/what-is-maven.html)
  • http://ant.apache.org/manual/developlist.html
  • [interessant!] http://properties2java.jayefem.de/ - Properties2Java is an Ant task for automatic conversion of java ".properties" files to ".java" files extending the java.util.ListResourceBundle - könnte man vll. benutzen, um von Ant verschiedene Properties-Files für jeden Sensor beim starten mitzugeben
  • http://antforms.sourceforge.net/usageaf.html - Vielleicht verwendbar für GUI um beim starten die Anzahl und Eigenschaften der Sensoren festzulegen
  • http://www.ggtools.net/grand/#examples oder http://www.nurflugel.com/webstart/AntScriptVisualizer/ - Visualisierung von Ant - Tasks und ihren Abhängigkeiten ... ganz nett
  • http://www.java2html.de/#screenshot - generiert html aus Java-Code, mit Syntax-Higlighting und allem, ganz nett für Dokumentation
  • http://jreleaseinfo.sourceforge.net/intro_d.html - erzeugt zu Laufzeit eine Java-Klasse die Informationen zum built enthält, bestimmt mal gut für die GUI um eben diese Informationen anzuzeigen.

Daniel

Problem Netzwerk

• im Uninetz mit verkabelten Rechnern:
  • Auskunft Ziv/Noc: Rechner im gleichen Subnetz, dadurch kein Blocken oder so von Routerseite etc.
  • Konfigurationen:
    • komplett ohne : Rechner finden sich nach ca. 15 Minuten, dann Probleme bei Registrierung, die registration_queue ist mehrfach vorhanden; statische Queue registration_destination im vcl Peer, dann funktioniert die Registrierung
    • feste Einträge der Peers in : wiederholt Fehler: "agent already exists, doing nothing"
    • komplett eingetragen in auf einem Rechner, regqueue nicht statisch: Registrierung von commsim und phen erfolgreich(!)
      • falls Einträge in worldmap nicht den richtigen Namen haben, kommt Fehler: A peer named <...> tried to connect, but does not appear in the world map. Closing connection <...>
    • alle Peers müssen dynamisch XOR statisch definiert sein
    • nachgefragt beim ziv bzw. noc: da die Rechner in einem Subnetz sind, wird eigentlich garnichts geblockt oder ähnliches
    • einmal haben sich die Rechner direkt gefunden. Möglicherweise verhindert die Windows-Firewall ein gutes AutoDiscovery: Standardmäßig lässt die Windows Firewall nach einem Multicast- oder Broadcast-Paket an dem entsprechenden Port eingehende Unicast-Pakete für drei Sekunden lang zu. (http://www.microsoft.com/germany/technet/datenbank/articles/600399.mspx#E2AAC)
• im Uninetz mit Laptop per WLAN:
  • Rechner nicht im gleichen Subnetz, dadurch erstmal keine Chance

langfristig

• VMWare Server auf einem Linux-Rechner, damit n-viele Rechner innerhalb eines virtuellen Subnetztes
• die SpecConns werden sich ähnlicher: ähnliche init - Methoden, gleiche Behandlung aller sendMessage-Methoden, isReady gleich (z.Z.), get...Queues gleich ... >> umbauen mit abstrakter Klasse
• aufnehmen von exit() - Methoden, die ordentlich die Connections und Requests und so weiter schließen
• einbeziehen von ThreadGroup zur Organisation der Threads? Vll. eine Gruppe pro Sensor - Instanz?
• da es keine unterschiedlichen insertMessage - Methoden mehr im CC gibt, wird die Behandlung von fehlenden Informationen in die SC verlagert, was auch Sinn macht, da dort dann analog zu den überhaupt existierenden Anwendungsfällen bzw. zum existierenden Mapping im jeweiligen IDictionary eine Fehlerbehandlung bzw. Fehlerwerfen eingerichtet werden kann. Z.B. könnte sendMessage ohne recipients im PhenomenConnector gleich eine IllegalArgumentException werfen.
• Management-Console langfristig vll. mal in eigenen Tomcat deployen und nicht nur über batch-Datei, vll. kennt sich ja jemand mit struts aus.
• auch die CommunicationSimulation sollte einen (limitieren) Pool an Threads haben, die die Anfragen parallel arbarbeiten, in Analogie zu ServerSocket, das ein neues Socket erzeugt, sobald eine Anfrage kommt und weiter lauscht. Kommt dann darauf an, wie aufwändig die Berechnungen zur Erreichbarkeit sind.
• Text-Chat
• GUI mit eingehenden und ausgehenden Nachrichten

Archiv

• [OK] logging konfigurieren: mantaray hat seine eigenen logging einstellungen, dadurch wird log4j 2mal gestartet. Workaround: logging in xml Datei konfigurieren und diese in die mantaray config xml importieren.
• [OK] phenomenon type als dictionary oder int, auch in letzen fall sollte es eine statische klasse geben, wo diese gespeichert sind. Lösung: als int, später mal eine PhenomenonTypeRegistry mit encode(String lala) und decode(int i)
• [OK] wo werden überall aufrufe mit verschiedenen messages gemacht, um das mapping der typen zu ermöglichen? Lösung: in DestinationNameFactory.getQeueForAnything() das Argument Class<? extends ISpecificConnector> c eingefügt
• [OK] add ist überschreibend oder nicht? Lösung: add = hinzufügend, siehe =replace(...) in TasksOne, außerdem gibt es ja delete(...)
• [OK] der Fehler ist auch beim erzeugen des Requestes in MantaSession, Zeile 919, Selector s = new Selector(messageSelector); ... habe antlr.jar in den lib ordner gepackt ... mit dieser auf dem classpath kommt der Fehler nicht mehr! ... die war im letzen Projekt auch drin, und inzwischen meine ich mich zu erinnern, dass ich die dort auch hingepackt habe, da mir die antlr - Hompage irgendwie bekannt vorkam. Aber hiermit ist das ja angemessen dokumentiert.
• [OK] update aus RegistrationMessage und die entsprechenden Methoden aus DictinaryControl entfernt
• [OK] javax.jms.MessageFormatException: MNJMS00016 : FAILED TO INSTANTIATE OBJECT ON METHOD makeObject(). ERROR TEXT - Lösung: die eigentliche Lösung ist, dass die Klassen, die in einer ObjectMessage verpackt werden sollen, auch Serializable implementieren müssen. Nichtsdestotrotz sollten Sensor etc. nicht Serializable implementieren, sondern wirklich nur Objekte, die wir hin und her schicken.
• erstmal werden nur DictionaryMessages mit dem Task NEW_DICTIONARY versendet
• brauchen wir update und delete methoden für die dictionaries (und wenn dann ohne convenience methoden, sondern eine update oder delete nachricht pro destination) wirklich? wiederum dafür dann entsprechende update und delete messages. der jeweilige task könnte im message header verpackt sein.
• ÜBRIGENS: der Fehler, das ich keine Sensoren verschicken konnte, lag schlicht und einfach daran, das nicht das Serilizable Interface implementiert wurde ... finde das allerdings auch eine hinreichende Begründung für die Existenz von SensorWorldProperties. Habe aus diesem Grunde auch die Folgenden änderungen gemacht, weil diese in einigen Nachrichten verwendet werden
  • Geometry extends Serializable
  • Measurement implements Serializable
• [OK] Nebenläufigkeit
  • SC und CC kommunizieren über zwei Queues, Queue für SC an CC und Queue für CC an SC
    • signaturänderungen: sendMessage fliegen komplett aus den CC raus, ebenso insertMessage aus dem SC
  • SC und CC müssen auf einer Ebene als unabhängige Threads laufen, deswegen wir der Konstruktor vom SC um einen ExecutorService erweitert, mit dem der zugehörige CC (oder auch weitere Threads) dann ausgeführt wird. Jede Komponente muss selbst managen, dass die Vernünftig als Threads parallel laufen.
• [OK] die behandlung von RegistrationMessages kann doch eigentlich aus der onMessage() des CC raus, weil das ja über einen request in der Methode register() geregelt wird.
• [OK] die signatur von sendMessage(SWM msg, int[] recs) zu sendMessages(SWM msg, int[] recs) ändern um klarer unterscheiden zu können
• [??] register ist blockierend, kann er auch ruhig sein, wass soll der CC sonst auch tun. Um dieser Tatsache gerecht zu werden, wird eine isReady Methode in beide Connectoren eingearbeitet, die dem Verwender (Highlevel-Komponente) Information darüber liefert, ob eine Nachrichtenabarbeitung stattfinden kann. Auch wenn der SC nicht ready ist, können Nachrichten gesendet werden, diese bleiben dann jedoch in der Queue vom SC zum CC. Die verwendende Komponente kann dann selbst entscheiden, ob sie auf den ready - state des SC wartet oder nicht. Der SC ist ready gdw. der zugehörige CC ready ist und möglicherweise noch weitere Kriterien. Der CC ist ready gdw. er sich erfolgreich registriert hat und damit auch initialisiert ist.

• verbinden mehrerer peers auf verschiedenen Rechnern, verschiedene Konfigurationen funktioniert!
  • lokal im Netzwerk testen, direkter Anschluss an Switch
    • Rechner in Raum 44 haben zweite Netzwerkkarte
    • zweite Netzwerkverbindung mit festen IPs, Firewalls KEINE Ausnahmen --> Probleme hattten nichts mit Firewall zu tun!
    • sofortiges erkennen, Registrierung klappt
    • die Netzwerkverbindung zum Uni-Netz muss deaktiviert werden, Vermutung: Mantaray versucht dann über beide Netzte nen multicast und das dauert wieder ewig

• habe ein ordner lib-src erstellt, damit man einen vernünftigen src-lookup einrichten kann für den workspace bzw. zumindest die vorhandenen srcs entpackt werden könnten
• laut http://www.antlr.org/license.html ist antlr public domain
• es gibt 2 Speicherorte für persistent
  • /persistent, wird von Peers benutzt, die aus Eclipse gestartet werden
  • Komponentenordner /persistent, wird von den .jar im Komponentenordner verwendet
• miniGUI erstellt für Phenomen und Sensor, dadurch kann man den vcl und die commsim laufen lassen, wenn man am Phänomen oder am Sensor arbeitet und letztere registrieren, den sensor starten und stoppen, bei "gracefully" beenden. Dafür einige Methoden in die Abstract{Phenomenon,Sensor}Simulation hinzugefügt, die dann auch public sein mussten, finde das so aber schöner gekapselt als wenn die GUI in der Klasse drinhängt. Außerdem Änderungen an ICommonConnector und ISpecificConnector notwendig.