Parallele Timer

[Kris]

Hallo zusammen

Gegebenheit: JBoss 6, EJB 3.1

Ich muss zwei Threads laufen lassen. Einer liest den InputStream mehrerer Sockets aus un der andere prüft ob die Socketverbindung besteht und versucht sie beim nicht Bestehen wieder herzustellen.

Geht das mit Timern? Denn irgendwie scheint es mir so, dass diese nicht parallel laufen können.

Falls diesn nicht möglich ist, besteht, soweit ich das verstanden habe die Möglichkeit, alls über eine MBean laufen zu lasse. (In dieser Threads erstellen.)

Dort müsste ich die erforderlichen Beans über den InitialContext holen und könnte nicht mit den Notationen für DependencyInjections arbeiten.

Gibt es eine andere Möglichkeit oder einen Lösungsansatz?

 

[FArt]

Ich verstehe nicht genau was das bedeutet: "den InputStream mehrerer Sockets auslesen (in einem Thread?) und prüfen ob eine Socketverbindung besteht".

Vielleicht kannst du deine Anforderungen genauer beschreiben, denn bis jetzt sehe ich die Verbindung zur DI, also zu EJBs...

Prinzipiell: für jeden Thread könntest du einen Task schedulen (siehe z.B. [http://jaitechwriteups.blogspot.com/2010/07/ejb31-timerservice-in-jboss-as-600m4.html]).
Bei direkten Socketverbindungen solltest du immer sicher alle Verbindungen schließen und Ressourcen frei geben (nach jedem Durchlauf).
In einem MBean (XMBeans sind leicht zu realisieren) oder einem JBoss managed POJO kannst du nach belieben mit Threads und Sockets arbeiten. zu beiden Themen hast du jetzt die Stichwörter für eine erfolgreiche Google Suche. Bei JBoss gibt es aussagekräftige Beispiele in der Doku bzw. im Wiki.

 

[Kris]

Ich habe Funkempfänger, die permanant Signale empfangen. Diese müssen ausgelesen werden. Deshalb habe ich zu jedem Empfänger permanent einen Socket offen. Aus dessen InputStream wird permanent ausgelesen, was vom Empfänger empfangen wird.
Es kann aber natürlich immer der Fall auftreten, dass die Verbindung unterbrochen wird, z.B durch einen Stromausfall des Empfängers oder ein defektes Netzwerkkabel.
Deshalb soll immer überprüft werden, ob die Verbindung wieder aufgebaut werden kann.

P.S.: Der Link funktioniert nicht.

 

[FArt]

My Wiki: EJB3.1 TimerService in JBoss AS 6.0.0.M4

Ständig eine Verbindung offen halten solltest du mit keiner EE-Lösung. Dafür solltest du einen Service oder einen ResourceAdapter realisieren.

 

[Kris]

Hättest du einen guten Link für ein Beispiel mit dem Service oder ResourceAdapter?

Mit einem Task schedulen. Meinst du damit, die @Timeout Anotation in einem Bean?

 

[FArt]

Hättest du einen guten Link für ein Beispiel mit dem Service oder ResourceAdapter?

Mit einem Task schedulen. Meinst du damit, die @Timeout Anotation in einem Bean?

Google mit dem Stichwort "JBoss" und z.B. "ResoruceAdapter" oder "MBean" oder "XMBean" oder "managed POJO".

Ob ein ResourceAdapter das richtige ist, kommt auf die genauen Anforderungen an.

 

[Kris]

Was für Kriterien sind denn entscheidend?

Eine Sache ist, dass man dynamisch bestimmen müssen kann, wann welche Verbindung aufgebau werden soll. Das heisst, die IP-Adressen werden in einer Datenbank abgespeichert und dementsprechnend ausgewählt.

Wenn ich jetzt einen Service(MBean) nehmen würde, um die Socketverbindungen zu verwalten, geht da, bei jedem Verbindungsaufbau nicht Zeit verloren?

Zur Zeit ist die Socketverbindung in einer Connectorklasse (Stateful). Diese wird nur geschlossen, wenn die PreDestroy oder PrePassivate Methode ausgeführt wird. Ist dies wirklich eine schlechte Lösung?

 

[FArt]

Was für Kriterien sind denn entscheidend?

Eine Sache ist, dass man dynamisch bestimmen müssen kann, wann welche Verbindung aufgebau werden soll. Das heisst, die IP-Adressen werden in einer Datenbank abgespeichert und dementsprechnend ausgewählt.

Wenn ich jetzt einen Service(MBean) nehmen würde, um die Socketverbindungen zu verwalten, geht da, bei jedem Verbindungsaufbau nicht Zeit verloren?

Zur Zeit ist die Socketverbindung in einer Connectorklasse (Stateful). Diese wird nur geschlossen, wenn die PreDestroy oder PrePassivate Methode ausgeführt wird. Ist dies wirklich eine schlechte Lösung?

Technisch ist das Konsistent, denn die Sockerberbindung ist ja nur ein Clientsocket und wird ja vermutlich beim passivieren und beenden geschlossen und die Ressourcen freigegeben.

Aber du möchtest ständig auf dem Socket lauschen. Wie verträgt sich das damit, dass der Container dein EJB passivieren kann?

 

[Kris]

Ja in diesen Methoden wird der Socket geschlossen. Es wird ja ständig von dem Socket gelesen. Der Container passiviert dann nicht. Denn bei jedem auslesen, wird die Methode zum auslesen aufgerufen.

Also wäre mein nächster Versuch, ein Service (MBean) zu erstellen, in dem zwei Threads ausgefürt werden. Einer zum Prüfen und Wiederverbinden der Socketverbindung und der zweite zum Auslesen.

Besser wäre es sogar, wenn man für jeden Empfänger einen Thread machen würde, damit das Auslesen auch parallel erfolgt und nicht alle Empfänger in jedem Durchlauf nacheinander ausgelesen werden.

Gibt es etwas was gegen diesen Lösungsansatz sprechen würde, oder was man unbedingt beachten sollte?

 

[FArt]

Für mich sieht das SFSB derzeit als unnötige Indirektion aus, ohne Mehrwert für deine Applikation.

Die Umsetzung mit zwei oder mehr Threads hängt jetzt von deinen Bedürfnissen bzgl. Reaktionszeit und Ressourcenverbrauch ab, sollte aber funktioniell gleichwertig sein.

 

[Kris]

Beim deployen wird der Service, vor ausgeführt, bevor die Beans im JMX registriert werden.

Im Service wird aber per InitialNamingContext auf die Beans zugegriffen. Gibt es eine Möglichkeit den Service nach der Registrierung der Beans zu starten?

 

[FArt]

Man kann in den Deploymentdeskriptoren Abhängigkeiten über das Tag <depends> angeben. Es gibt auch eine Annotation @Depends .
Abhängigkeiten können nicht nur auf MBeans, sondern auch auf EJBs gesetzt werden.
Diese Abhängigkeiten werden beim Deployment aufgelöst und alles ist gut.

 

[Kris]

Ich habe aus den Statefull Beans jetzt auch einen Service gemacht.
Ich kriege die Objekte aber nicht mehr per InitialContext verbunden.

Muss man bei MBeans anders vorgehen?

 

[FArt]

Ich habe aus den Statefull Beans jetzt auch einen Service gemacht.
Ich kriege die Objekte aber nicht mehr per InitialContext verbunden.

Muss man bei MBeans anders vorgehen?

Ich bin mir nicht sicher, ob du weißt was du da machst. Learning by doing ist ja schön und gut, aber du musst dir auch mal die Theorie, Doku, Spec usw. reinziehen.

Ein MBean wird nicht am NamingService registriert. Wenn du das möchtest, muss du das selber machen, dabei aber natürlich einen passenden Stub bereitstellen.
Ein MBean wird (Überraschung!) am MBean-Server (JMX!) registriert.