Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to run an infinite loop in servlet

 
Jim Barkley
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.

I have a web service which serves as a central portal to accept some jobs that need to be sent to a remote machine. A javascript code stops the form submission, adds some necessary meta-data, and manually submits it to the servlet.


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.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64827
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An infinite loop is so far off the mark that's it almost mind-boggling. Your servlet needs to do a job and then return. Immediately.

Later HTTP request can check the status of job completion.

Search this forum for terms such as "long running process" for previous discussions.
 
Madhan Sundararajan Devaki
Ranch Hand
Posts: 312
Java MS IE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe, you should start an infinitely running Daemon Thread (from within the Servlet) that does what you want it to do.
 
elvadas nono
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18152
52
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13061
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Bill
 
Madhan Sundararajan Devaki
Ranch Hand
Posts: 312
Java MS IE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following is in response to Tim Holloway' post.

Tim, I have mentioned the words "Daemon Thread" in my post.

A Daemon thread can be started as the last statement of Servlet init method and can be destroyed in the Servlet destroy method.

The Daemon thread can monitor a static job queue, do the needful and sleep for a user-defined time period.

The Servlet may be made to just put the entries into the static job queue and return back to the caller, thereby allowing it to serve huge number of requests.

I am of the opinion that, this satisfies the requirements requested by Jim Barkley.

Kindly let me know if it is not so and the reasons please.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic