daemon threads in an app container

Question

I read in a post to the Smack forum recently that

Starting daemon threads in a Java EE server is a big no no

Basically Smack's XMPPConnection starts one daemon thread to monitor incoming data & another to send outgoing data from/to the jabber server respectively. Is it reasonable to use daemon threads to listen for write/reads in this scenario ?

Answer 1

Yes, XMPPConnection creates two threads--one for listening/reading and one for writing. But these only live as long as the XMPPConnection instance, which I assume is not forever.

"Starting daemon threads in a Java EE server is a big no no"

Are you writing spec compliant EJB? If so, then this applies. The spec says don't do it. EJB 2.1 specification:

"The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups."

Or is it just a webapp that happens to be running in Tomcat? If this is the case, then I do not see any fundamental problem. Without the threads, your Smack client would be unable to communicate with the server.

Answer 2

I have used Smack API for client connections only which are stand alone programs. First you should revisit the choice (or purpose) of Smack API inside a J2EE container.