Within the servlet, I want to have a "Job Queue", which will contain job information sent by the web service.
I want to have an infinite loop checking whether the job queue is currently occupied or not. If it is occupied, I will send the first available job to the remote machine.
My original plan was to run an infinite loop that checks on job queue, and I just learned that there's no main method in servlet(as they are not a standalone program).
I absolutely need this functionality because many people will be accessing this one portal to submit jobs, and I need some way of sending jobs to remote machines automatically.
How should I go about this? Help would be really appreciated. Thanks.
if you change the response after it has already been submitted using response.getPrintWriter.flush for example
the code throw an illegalStateException.
your Servlet has to do the job and return immediatly.
You can create many instances of your servlet class using Deployment descriptors.
Madhan Sundararajan Devaki wrote:I believe, you should start an infinitely running Daemon Thread (from within the Servlet) that does what you want it to do.
That would be a blatant violation of the J2EE specification.
The HTTP protocol is not a continuous-connection client/server architecture. As Bear said, it's about get in, do the work quickly, get out. If it wasn't for the magic of HttpSessions, each HTTP request would, in fact be totally independent of every other HTTP request/response process.
HTTP servers have an inherent "loop", where the server waits for incoming requests, parses them, then passes them on to threads from the internal thread pool. The thread should run the request/response lifecycle and then be returned to the pool so that it will be free for another, later request.
If an HTTP processor thread spawns child threads, they'll end up being returned to the pool, but they will no longer have the fundamental pooled thread characteristic of being just like every other thread in the pool, which means that the entire appserver can wildly malfunction in unpredictable ways. Including having other, equally invalid requests destroy or modify the child threads at any moment.
If you code an infinite (or long-running) loop in a servlet or JSP, that will tie up the thread, and if enough requests do that, eventually the thread pool becomes emptied and there's no more resources to handle later requests. It's also useless, since HTTP clients and servers do not converse. The HTTP request is a stream of data that comes into the server as a unit. That unit is them passed to the servlet. The servlet writes to the output stream. However, neither the servlet nor the output stream processes can/will accept any further input from the client. It takes an entirely new HTTP request to an entirely different servlet thread to accept more input.
It is possible, and not uncommon, for an appserver to run threads where the SERVER runs long-term asynchronous processes as a client to some other server, but those are not done through the appserver's serlvet/JSP functions.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
A separate Runnable class executing in it's own Thread and handling a "Job Queue" is certainly doable. Your request handling Thread would have to hand off a job and quickly return a response as everybody has been pointing out.
You should provide a servlet for management of this queue - password protected of course, that would let you monitor the performance and provide for controlled shutdown when necessary.
JavaSpaces could be used to coordinate the work of a variable number of remote machines, expanding the pool of workers as needed.