tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Running not multithreaded application
Date Fri, 23 Dec 2011 22:03:50 GMT
Hash: SHA1


On 12/23/11 4:24 PM, hernan wrote:
> Process p = Runtime.getRuntime().exec(...);
> // Sending input to process p OutputStream os =
> p.getOutputStream(); BufferedWriter bw = new BufferedWriter(new
> OutputStreamWriter(os)); [...] // send input through bw 
> bw.close(); os.close();
> // Receiving output from process p InputStream is =
> p.getInputStream(); BufferedReader br = new BufferedReader(new
> InputStreamReader(is)); [...] // receiving output through br 
> br.close(); is.close();
> I will add the stderr to this code.

If you just add similar stderr code after your stdout handling code,
you may still suffer a deadlock: if the stderr buffer fills up, the
child process will block waiting for you to read it, and output to
stdout will stall as well. I think the commons folks have a component
to handle all of this stuff for you in a tidy package.

> My next step is write a Scheduler class, may be a "singleton" or
> something similar to work as a resource-limiter, also I will need
> other rules related to users and sessions. Actually, when the
> threshold is reached, the Scheduler should queue the "job". For the
> moment I will think that the queue capacity is infinite :).
> I wonder which alternatives do I have to implement my Scheduler
> class in tomcat. In fact, I've to read a lot about tomcat, so I've
> started reading the apache tomcat 7 (Vukotic and Goodwill) to
> understand how tomcat works exactly.

I'm not sure that you need anything Tomcat-specific for this. Just
something that will work in any servlet container should be sufficient.

If you just want to limit resources and give anyone who exceeds the
limit a "sorry, try again" message, it shouldn't be too difficult to
implement with an atomic counter.

If you want to implement queuing, then you'll probably also want the
clients to continue to issue "update" requests to find out if their
job was completed. That will certainly be more complicated, but
probably more robust. You'll want to look at Java's "executors" for
that: you can queue a job and get a "Future" object that you can poll
for completeness. Stick that object in the session after queuing the
job and use something like META REFRESH or Ajax calls to periodically
check the status of the job. If the user logs out, you might want to
mark the job as cancelled just so you don't waste your time. I would
also *not* allow an infinite queue length.

There are of course lots of other ways to do this kind of thing.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message