web application with multithreaded sockets

[Pavel Kazlou]

Hi everyone.
I am to develop web application under Tomcat that should allow its users to communicate with certain devices. These devices use GPRS to connect to my web application. Thus, my web application should provide a range of ports for devices to be able to connect to. This implies having a sort of thread pool where each thread is waiting for connection on the corresponding port.
The question is: should I implement thread pool inside web app under Tomcat or move it to a separate standalone application? In general - is it a good approach to allow web application under Tomcat to spawn threads? Will any difficulties arise while letting socket connection pass through Tomcat?

[Ninad Kulkarni]

Hi, Pavel

Welcome to JavaRanch.

This implies having a sort of thread pool where each thread is waiting for connection on the corresponding port.

Would you explain above statement briefly

should I implement thread pool inside web app under Tomcat

You should use fullform of words like application instead of app so everyone will understand properly.

It depend upon the situation but I think you should implement under web application.

[Ulf Dittmer]

Why does the application need to listen on multiple ports? Tomcat (like all web and app servers) is multi-threaded, and can handle multiple clients connecting on the same port simultaneously.

[Pavel Kazlou]

Thank you guys for such quick replies!
Excuse me in case my english is bad or I express something unclearly.

Ninad Kulkarni wrote:
Would you explain above statement briefly

To initiate a connection my web application sends message (to be more precise, SMS message) to device where the exact values of IP and port are specified. The device then use this information to connect to my web application through GPRS. For the web application this communication appears as plain socket communication (web application being a server who accepts and device being a client who connects). So, the scenario is: web application get the request from customer -> web application sends message to device saying "Connect to me on IP x and port y" -> web application spawns a thread waiting to accept socket connection.
As my web application may be used by several customers at the same time I need to provide the ability to open concurrent socket connections on different ports. Thus, I need thread pool.

Ulf Dittmer wrote:Why does the application need to listen on multiple ports? Tomcat (like all web and app servers) is multi-threaded, and can handle multiple clients connecting on the same port simultaneously.

The problem is that the protocol used for communication between web application and device is plain TCP/IP. As long as I start communication with device using socket on port Y I must hold the connection till all the data is transmitted and socket is closed (and this may take some time as the user begins entering information only after the connection is established). It makes impossible for web application to open additional connection on port Y. So I need to use a range of ports to allow multiple devices to connect to my web application simultaneously.


I hope I explained the situation better now =) Thank you guys, waiting for your suggestions.

[Ulf Dittmer]

Pavel Kazlou wrote:The problem is that the protocol used for communication between web application and device is plain TCP/IP. As long as I start communication with device using socket on port Y I must hold the connection till all the data is transmitted and socket is closed (and this may take some time as the user begins entering information only after the connection is established). It makes impossible for web application to open additional connection on port Y. So I need to use a range of ports to allow multiple devices to connect to my web application simultaneously.

Have a look at the ServerSocket class and the Networking chapter of the Sun Java Tutorial. It shows how to build a server that can accept multiple connection (which are simultaneously open and in use) on a single port. You will need to start multiple threads, but you don't need multiple ports.

[Pavel Kazlou]

Ulf Dittmer wrote:
Have a look at the ServerSocket class and the Networking chapter of the Sun Java Tutorial. It shows how to build a server that can accept multiple connection (which are simultaneously open and in use) on a single port. You will need to start multiple threads, but you don't need multiple ports.

Oh thank you (shame on me, didn't even think of such a possibility!). This makes things a lot easier.
But still the questions: is it a good idea to let web application spawn a number of threads? What is the best way to associate accepted connection with HTTP session?

The scenario looks like this:
1) as the result of user's HTTP request a message is sent to device asking the device to connect to my web application. The id of device is stored in HTTP session.
2) a thread which resides in the background looking to accept a connection on port suddenly captures device's attempt to connect and accepts it. The thread also reads the id of device from the socket.
3) ... some unknown magic is done to associate acquired Socket object with HTTP session of the user based on the equality of device id that is stored in HTTP session and device id that is read from socket.
4) subsequent user's HTTP request brings some values and transfer them to the device using associated Socket object

Everything is clear except the 3rd step. I don't know how to bind Socket object to some HTTP session while being out of this session (the thread which accepts connection runs in background outside of any HTTP session). Any suggestions?

I apologize for asking some mess of questions which has gone off the topic "Tomcat".

[Tim Holloway]

Excuse me if I'm wildly off-base here, since I haven't yet digested all this, but I figured I'd contribute some general info about network connections in Tomcat (and webapps) that might possibly help.

First of all, the primary responsibility of a web application server is to serve HTTP requests, and an HTTP request consists of a definite cycle where the client sends a request, the server builds a response, sends it, and the listens for the next request (typically several threads worth of that process running in parallel). Therefore, you should never make the primary request process wait on ANY sort of activity (other than short-lived things like file or database I/O). Otherwise you stall the processor threads, and if you do it enough time, end up running out of processor threads entirely.

I think that was understood here, but I'm trying to be complete and explicit. Any extraneous port-parking needs to be done by an auxiliary thread, not the main request thread, and since the main request thread shouldn't return to idle with resources hanging off of it (child threads), the auxiliary threads need to be launched and maintained outside the request-response environment (that is, by an init() method in a servlet, or some similar mechanism).

Secondly, the Core Servlet class is a generic listener/handler all by itself. It can be used (directly or as a base class) for other things besides HTTP requests, although I've not seen anyone actually do so. But that's why it's a parent of HttpServlet instead of HttpServlet being self-contained. So there's a possibility there.

Thirdly, Tomcat is an expandable architecture. It might be worthwhile to make this auxiliary service be an independent engine bolted on to the Tomcat framework instead of having to re-invent the functionality and architecture yourself. That's especially true should you decide to use the Servlet class as your basis.

So much for listening ports and mechanisms. As far as sessions go, that's a little trickier. The HttpSession is a transient object created and maintained for the benefit of a particular client/server conversation. Since HTTP is a series of "one-off" request-response cycles, the Session is a way to make what would otherwise be stateless be stateful. In the case of the normal web process, the session has an ID that keys into the session storage within the server and attaches the session and its related objects to a given request based on that key so that clients and their sessions are properly matched up. The session ID is provided either as an appendage to the outgoing URL or in a cookie (or sometimes both places).

Because the session is created and destroyed within the context of a web application, it's not really reliable for use anywhere else. The session may be timed out and invalidated by the HTTP/JEE Server, not created yet, or even explicitly destroyed by the primary webapp. Furthermore, there's no API to obtain the session ID (which is proper, since it's not supposed to be meddled with outside of the J(2)EE API), nor is there a guaranteed way for extra-webapp code to resolve that ID into a Java HttpSession object. All the more so, since in extreme cases, that might require fetching the session data and reconstructing the session object from serial storage in the case of servers running clustered or doing session "paging".

So if you want to tie a webapp and an independent serving process together neatly and reliably, you'll need to provide your own mechanism.

[Pavel Kazlou]

Thank you, Tim, for such complete and clear explanation. It really helps to stop thinking of wrong ways to solve my problem =)
Extending tomcat's standard functionality is a very interesting idea, but some time should be spent as my knowledge of tomcat architecture is very basic. I'll report back in case of a successful solution using this approach.
As for session accessing my googling bring me to an interesting interface in servlet API - HttpSessionContext. It was deprecated long time ago making sessions know nothing about each other and proving the concept of working with session only in scope of request.

At the moment I have no clear idea of how to solve the problem, but thanks to you guys I can narrow down my choices to some particular and viable (I hope!) solutions =)