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