-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hernán,
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk70+sYACgkQ9CaO5/Lv0PC5HgCfeTdI8bVDgMXuln0HW2tdnuxo qFYAniTf6OSaeES8Fi69yJBfbcpRGJNW =KSqB -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
