On Thu, Dec 15, 2011 at 4:48 PM, Christopher Schultz < ch...@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
