thread demone in un contenitore app

Question

Ho letto in un post al forum Smack recente che

  

A partire thread demoni in un server Java EE è un grande no no

Fondamentalmente XMPPConnection di Smack inizia un thread demone per monitorare i dati in ingresso E un altro per inviare i dati in uscita da / verso il server jabber, rispettivamente. E 'ragionevole utilizzare thread demoni per ascoltare per la scrittura / lettura in questo scenario?

Answer 1

Sì, XMPPConnection crea due thread - uno per l'ascolto / lettura e uno per la scrittura. Ma questi vivono solo fino a quando l'istanza XMPPConnection, che presumo non è per sempre.

  

"Avvio thread demoni in un server Java EE è un grande no no"

Stai scrivendo specifica EJB compatibile? Se è così, allora questo si applica. La specifica dice di non farlo. EJB 2.1 specifica:

  

"Il fagiolo di impresa non deve tentare   gestire thread. Il bean enterprise   non deve tentare di avviare, arrestare,   sospendere o riprendere un filo, o per   modificare la priorità o il nome di un thread.   Il fagiolo di impresa non deve tentare   per gestire gruppi di thread ".

O è solo una webapp che sembra essere in esecuzione in Tomcat? Se questo è il caso, allora non vedo alcun problema fondamentale. Senza i fili, il client di Smack sarebbe in grado di comunicare con il server.

Answer 2

Ho usato Smack API per connessioni client solo che sono programmi stand alone. In primo luogo si dovrebbe rivedere la scelta (o scopo) di Smack API all'interno di un contenitore J2EE.