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 (athena.apache.org: local policy)
Message-ID: <4EEA4F29.7050203@christopherschultz.net>
Date: Thu, 15 Dec 2011 14:48:57 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:8.0) Gecko/20111105 Thunderbird/8.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>
In-Reply-To: 
 <CAAup0kavvYZWnL4g3QnWW-=ZhDWC6cXo5N5mt3Uy=N-ccy-rMw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hernan,

On 12/15/11 12:47 PM, hernan wrote:
> As separate process, I thought a java "server" process with the 
> wrapper that receive requests, launch a new process an response
> with the result. The servlet (thread) calls the process using some
> kind of client/server mechanism implemented in java (may be
> sockets).

So in order to avoid calling Runtime.exec() from Tomcat, you're going
to write another service that mimics quite a bit of what Tomcat does,
and then call Runtime.exec() from that? Hrm.

So, you'd have this:

Client -> Tomcat -> GLPK Service -> Java Wrapper (GLPK)

That seems entirely unnecessary.

> I agree, just doing Runtime.exec(binary), the disadvantage with
> Runtime is that I'll not use java classes to comunicate
> input/output of the process.

Aah... so GLPK generates output that is better consumed as serialized
Java objects? What about on-disk artifacts or some kind of non-binary
output? I'm just thinking out loud. I hate Java serialization in most
cases.

> I've run successfully using syncronized methods, but I have to
> handle concurrent requests and I don't want to serialize them
> because the response times may be very different between them and I
> don't want some user have to wait a lot for a "simple" request.

Yup. Makes sense. That pretty much rules-out in-process use of GLPK.

Are there any plans from the GLPK folks to make their code threadsafe?
That would certainly be nice...

> This is the main concern for me. For that reason I prefeer run glpk
> in a different os process. I see two big ways: serving each servlet
> request with a different process or run a different process/es
> dedicated only to glpk. The first way is what I have to learn, but
> it seems that tomcat does not support. In the second, I have more
> job coordinating processes and manipulating input/output.

I would start-out just using Runtime.exec() and communicating via
stdin/stdout with (I guess) serialized Java objects. That seems so
disgusting to me, but it's slightly less odious than writing a TCP/IP
service wrapper to essentially do the same thing.

> In my experience GLPK is stable, and I've been doing some
> (serialized) tests on java wrapper and they run successfully. But
> I'm not 99% sure that will be perfect, and mainly I don't trust in
> the program/programmer (me) that uses the library. I don't want
> that tomcat crash due to some request.

That's a good policy.

> Connecting apache htttpd server with tomcat, can I run several
> tomcat instances and run each http request in a different tomcat
> instance?

Uh, yes, but not the way you want to. It sounds like you want to run
Tomcat like an inetd-style service, which is going to get you nowhere.
It takes Tomcat so long to start up that you may as well just
serialize access to your GLPK library. Actually, I'll bet Tomcat can't
even be used as an inetd-style service.

> I know that this is not the tomcat philosophy, but I just want to
> know if it is possible or is common this approach for this kind of
> situations.

Er... you may be able to beat it into shape, but it will be horribly
unstable and just a terrible all-around idea. Look elsewhere.

> My principal requirements are: stability (main concern),
> scalability, serving concurrent requests (no more than 100
> concurrent requests). If possible: flexibility/maintainability.
> 
> I think that your option #4 is the appropriate in this situation.

Do you have any opportunities for batch-processing these requests?
That way, an HTTP request essentially amounts to a queuing operation.
You have a single-threaded, background process that does the "real"
work (possibly by running multiple, parallel copies of GLPK) and
deposits an artifact for each task somewhere (database, on-disk file,
etc.). That might simplify the architecture. *shrug*

This doesn't seem like a simple thing to do in general. Is there high
demand for linear-physics-via-HTTP processing?

- -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/

iEYEARECAAYFAk7qTykACgkQ9CaO5/Lv0PBr1wCfQvMwnBPYIrJ33QhuRRX6R4gm
FOcAnRLfchlvlMW+dY91k5qWsO+npukt
=fA6f
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org