Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of hberig@gmail.com designates
 209.85.212.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EEA4F29.7050203@christopherschultz.net>
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>
Date: Thu, 22 Dec 2011 23:47:20 -0300
Message-ID: 
 <CAAup0kanLucdfn=AaKxSOWsFdAOCfcXZRmWam6daaMYvwS23_Q@mail.gmail.com>
Subject: Re: Running not multithreaded application
From: hernan <hberig@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=20cf3071cf3a97716204b4b96f22

--20cf3071cf3a97716204b4b96f22
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 15, 2011 at 4:48 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

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


Finally, I'm just using Runtime.exec() to execute a c++ program that uses
glpk, and using stdin/stdout to communicate them. The whole system is
running tomcat, axis2, java and c/c++.

I don't know about the demand for linear-physics-via-HTTP, it's only about
a service for inventory and order management.

Thanks a lot for your comments and suggestions!!!

Regards,
Hern=E1n

--20cf3071cf3a97716204b4b96f22--