ich in a post zum Smack Forum vor kurzem gelesen, dassDaemon-Threads in einem App-Container
Start Daemon-Threads in einem Java EE-Server ein großes ist kein keine
Grundsätzlich Smack der XMPPConnection beginnen einen Dämon Thread, um eingehende Daten zu überwachen & ein anderer zu senden ausgehende Daten von/zum Jabber-Server jeweils. Ist es sinnvoll, in diesem Szenario mit Daemon-Threads auf Schreib-/Lesevorgänge zu warten?
Ja, XMPPConnection erstellt zwei Threads - einen zum Abhören/Lesen und einen zum Schreiben. Aber diese leben nur so lange wie die XMPPConnection-Instanz, von der ich annehme, dass sie nicht für immer ist.
"Starten Daemon-Threads in einer Java EE-Server ist ein großer nein nein"
Schreibst du spec konforme EJB? Wenn ja, dann gilt dies. Die Spezifikation sagt, tu es nicht. EJB 2.1-Spezifikation:
„Der Enterprise-Bean darf nicht versuchen, auf Threads zu verwalten Der Enterprise-Bean darf nicht starten versuchen, zu stoppen, aussetzen oder einen Faden wieder aufzunehmen, oder zu Änderung eines Threads Priorität oder. name. Die Enterprise-Bean darf nicht versuchen, Thread-Gruppen zu verwalten. "
Oder läuft gerade eine Webapp in Tomcat? Wenn das der Fall ist, sehe ich kein grundsätzliches Problem. Ohne die Threads könnte Ihr Smack-Client nicht mit dem Server kommunizieren.
Ich habe Smack API nur für Client-Verbindungen verwendet, die eigenständige Programme sind. Zuerst sollten Sie die Auswahl (oder den Zweck) der Smack-API in einem J2EE-Container überprüfen.
Ich bin eigentlich mit der Pflege einer bestehenden Codebasis geladen, die bereits Smack in Tomcat verwendet. Was sind die Gründe gegen die Verwendung von Smack in Tomcat (oder einem j2ee-Container)? –
Es ist das letztere (Webapp auf Tomcat). Vielen Dank für Ihre Kommentare. –