File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes JBoss/WildFly and the fly likes JBoss and user threads and sockets Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "JBoss and user threads and sockets" Watch "JBoss and user threads and sockets" New topic

JBoss and user threads and sockets

Atanas Todorov

Joined: Nov 29, 2005
Posts: 3
We use the last version of JBoss with EJB3.

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?
S Davis
Ranch Hand

Joined: Feb 07, 2006
Posts: 40
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.

Could your socketListener really just be a servlet listening on port 80 (or the port number of your choice)? If not, I would look into creating a custom MBean -- JBoss is a JMX server, and snapping in a service would make the most sense. See for details.
Tom Marrs
Ranch Hand

Joined: Sep 20, 2000
Posts: 67
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.
Atanas Todorov

Joined: Nov 29, 2005
Posts: 3
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).

What do you think about it?
Fred Grott
Ranch Hand

Joined: Oct 05, 2002
Posts: 346
hmm, a socket factory?

It is detailed inthe JBoss docs..

or google search for it..

MobileBytes blog - Sharing Technology - My Programming Knols
I agree. Here's the link:
subject: JBoss and user threads and sockets
It's not a secret anymore!