Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4EF4FAC6.6090207@christopherschultz.net>
Date: Fri, 23 Dec 2011 17:03:50 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Running not multithreaded application
References: 
 <CAAup0kYKA5mfRL1qQ+Kdm-=7Zp=R+yqC_f1O1oCaaciDSWPfSA@mail.gmail.com>
 <4EE92E9D.3010606@christopherschultz.net>
 <CAAup0kZi0+SPKFw-OPy-GraycvXHq8EXDZqGXj02FXNoJZ2mpQ@mail.gmail.com>
 <4EEA115E.2060201@christopherschultz.net>
 <CAAup0kavvYZWnL4g3QnWW-=ZhDWC6cXo5N5mt3Uy=N-ccy-rMw@mail.gmail.com>
 <4EEA4F29.7050203@christopherschultz.net>
 <CAAup0kanLucdfn=AaKxSOWsFdAOCfcXZRmWam6daaMYvwS23_Q@mail.gmail.com>
 <4EF49779.9070005@christopherschultz.net>
 <CAAup0kaQZQD_NE51WwDA=-V8VLFGFJYxZpX63i-y+cbNLe+KFw@mail.gmail.com>
In-Reply-To: 
 <CAAup0kaQZQD_NE51WwDA=-V8VLFGFJYxZpX63i-y+cbNLe+KFw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org