This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
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 The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "JBoss and user threads and sockets" Watch "JBoss and user threads and sockets" New topic
Author

JBoss and user threads and sockets

Atanas Todorov
Greenhorn

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
Author
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 http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch2.chapter.html for details.
Tom Marrs
Author
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
Greenhorn

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
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: JBoss and user threads and sockets