tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hernan <hbe...@gmail.com>
Subject Re: Running not multithreaded application
Date Fri, 23 Dec 2011 02:47:20 GMT
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Ă¡n

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message