Reading from a non-HTTP socket in WL; same idea as WL.system.listenPort

Question

Hi Fellow EJBers,
I have a system which must listen on a TCP port that is not the normal
WebLogic port nor the standard HTTP port for client connection
requests. Unfortunately, the protocol is low-level TCP/IP sockets and
as it's coming from a legacy system I cannot change. What I'd like to
do is create a startup class in the EJB server that listens to the
correct port and then hands off the socket ID to a bean for further
processing. Then when the response is ready I can use a simple socket
write() method.
I am hoping that this will allow me to use WebLogic's built-in threading
support in this class. I was hoping to find some way to imitate the
WebLogic properties file entry
weblogic.system.listenPort=7001
but I didn't see any references to it in the documentation. Can I use a
servlet or startup class to do this? I don't want to use events if I
can help it to maintain compatibility. Alternatively, I'm thinking
about using a separate Java process running in a different JVM which
would manage the threading issues. This is less desirable because it
complicates sending responses back and I don't know if I can pass the
socket reference into EJB.
Note that right now I'm only worrying about the listening portion, I
must also send requests out to different machines but here I control the
initiation.
Thanks for any and all help,
Terry ([email protected])

Answer 1

Rob,
Could you please explain why you should not create worker threads in the server.
I created a GenericServlet and installed it in the ServerClasses so it does not
ever get more than one instance - it listens on a server socket (in a thread) and
accepts connections and allows replies to the
connected socket. I use it for debugging where you connect to the port with Telnet and
each developer that wants to output a debug string from a JSP back to their Telnet can
do so. It works fine.
I don't want to screw the server up so please enlighten me.
Joe
Rob Woollen wrote:
If you have a legacy system that is sending data over TCP/IP sockets, you have
to have a socket for it somewhere. It's certainly not an ideal situation since
WebLogic already provides these basic services for you, just not for an arbitrary
protocol.
You definitely should not create worker threads in the server. Use WebLogic
events or JMS instead.
-- Rob
Rob Woollen
Software Engineer
BEA WebLogic
[email protected]
Russell Castagnaro wrote:
Rob,
Is it OK to start your own threads that listen on a particular port? I've been
informed over and over again that this is a recipe for disaster. If it is
acceptable to start up a port listener thread at some times, when is it
acceptable and when isn't it? (I know not to do it with Servlets or EJB's)
Thanks in advanced..
Russell
Rob Woollen wrote:
Hi.
Terence Davis wrote:
Hi Fellow EJBers,
I have a system which must listen on a TCP port that is not the normal
WebLogic port nor the standard HTTP port for client connection
requests. Unfortunately, the protocol is low-level TCP/IP sockets and
as it's coming from a legacy system I cannot change. What I'd like to
do is create a startup class in the EJB server that listens to the
correct port and then hands off the socket ID to a bean for further
processing. Then when the response is ready I can use a simple socket
write() method.
Okay, that seems reasonable. Note, that EJB 1.1 (the next version of
the spec) prohibits bean writers from directly reading or writing sockets.
I am hoping that this will allow me to use WebLogic's built-in threading
support in this class. I was hoping to find some way to imitate the
WebLogic properties file entry
weblogic.system.listenPort=7001
but I didn't see any references to it in the documentation.I'm not sure that I follow. You could use your own properties file if
you want to configure a listen port for your socket.
Can I use a
servlet or startup class to do this? I don't want to use events if I
can help it to maintain compatibility.JMS (available in 4.5.x) is a J2EE standard tha has a superset of the
events functionality.
Alternatively, I'm thinking
about using a separate Java process running in a different JVM which
would manage the threading issues. This is less desirable because it
complicates sending responses back and I don't know if I can pass the
socket reference into EJB.
Note that right now I'm only worrying about the listening portion, I
must also send requests out to different machines but here I control the
initiation.
Thanks for any and all help,
Terry ([email protected])
Russell Castagnaro
Chief Mentor
SyncTank Solutions
http://www.synctank.com
Earth is the cradle of mankind; one does not remain in the cradle forever
-Tsiolkovsky