We need to start a TCP/IP ServerSocket in our JBoss application, listening all the time the app is running. Is there a problem to do this in JBoss? Is it allowed, and is there a danger JBoss to decide to influence the thread(s) I start?
By the way, the EJB specification (for both 2 and 3) states that:
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.
Well, they say "The enterprise bean must not attempt to manage threads". But does it mean that this restriction is not related to other classes deployed in the EJB container?
JBoss is called a J2EE "container" for a reason -- it is meant to handle the low-level port management stuff and threading stuff on your behalf.
For example, you don't have to write code to listen on a specific port like port 80 -- you write a servlet that implements the proper interface (doGet, doPost) and let the container manage the ports for you. You don't worry about threading issues -- the container creates a pool of servlet instances and doles them out on a per-request basis.
All of the services that JBoss (and the J2EE spec) brings to the table fits this model -- you implement an interface, and let the container manage ports and threading for you.
Make sure that you're *not* doing this from an EJB, because this is forbidden in the EJB specification. It's forbidden because J2EE servers (including JBoss) have their own threading and socket-handling model.
Like Scott said, JMX could fit the bill nicely.
Joined: Nov 29, 2005
Thanks for your reply guys!
A servlet would not be the proper way to handle this, because I need a direct TCP/IP communication (not HTTP or other higher-level protocol).
Actually we use the bundled Tomcat in our application. The servlet specification (in contrast to the EJB spec) does not restrict the developer to handle it's own, independent threads. So, if I implement the ServerSocket listening in the web container part, the EJB container should not be concerned about it (although tomcat is running in the same VM).