On 15 Dec 2011, at 17:56, hernan <hbe...@gmail.com> wrote: > On Thu, Dec 15, 2011 at 12:27 PM, Pid <p...@pidster.com> wrote: > >> On 15/12/2011 00:15, hernan wrote: >>> On Wed, Dec 14, 2011 at 8:17 PM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hernán, >>>> >>>> On 12/14/11 5:45 PM, hernan wrote: >>>>> I'm using Tomcat 7.0 for developing a new application. A key >>>>> component in the application have to run an external not >>>>> multithreaded application. >>>>> >>>>> Since I'm not an experienced user in Tomcat, I wonder which >>>>> implementation alternatives do you recommend for running my >>>>> external application. I'm trying to avoid launch a new os process >>>>> from java since I need the result of that process, so in this way >>>>> I've to deal communicating two processes (may be using serializable >>>>> objects using sockets). >>>> >>>> So, is this other program a Java program? Since you said >>>> "serializable" you probably are talking about running another Java >>>> "program". >>>> >>>> What makes this "external" "program" non-multithreaded? Is it actually >>>> not threadsafe? >>>> >>>> If you can't run it in the same process as Tomcat, then you'll have to >>>> either use Runtime.exec or some type of wrapper around it -- or have >>>> that process running completely separately (as a daemon) and connect >>>> to it via sockets. Anything else requires native code, which you >>>> definitely don't want. >>> >>> >>> My external application is a java application that uses java wrapper >> (using >>> JNI) for GLPK (written in ANSI C) (http://www.gnu.org/s/glpk/), and >> GLPK is >>> not threadsafe. Yes, I will consider those alternatives, executing a new >>> process when I receive the request (Runtime.exec) and a separated deamon >>> receiving requests launching those processes. >> >> Can you not import the application Jars and just interact with them >> directly then? Why do you have to interact with it via system process? >> > > If I do that, due to glpk is not threadsafe, a call to a method can crash > tomcat.
I don't know what glpk does, can you explain? I think you may be over thinking the thread safety issue. If multiple threads can't access the instances of the thing, thread safety is not an issue. If the entire code block was instantiated inside a Servlet doGet method with no external exposure or external scope, there is no problem. Do you know why it is not thread safe? p > I can use glpk via a synchronized method, but I don't want to > serialize the server requests, since I want run a fair service: "heavy" > input have to wait more than a "light" one. > > >>>>> I want to know which kind of approachs are used to deal with these >>>>> type of situations. >>>> >>>> What about running in-process? Even if the class(es) is(are) not >>>> threadsafe, you might be able to use separate instances from your >>>> request processor threads. >> >> +1, see above. >> >> >>> Can I configure tomcat for running a new (or different) process for each >>> request? >> >> "configure"? Not really, you can write a Servlet to do that, if you >> wanted to. (I wouldn't think that's a good idea, myself). >> >> >>> or I have to run Apache HTTP Server and connect it to Tomcat? >> >> Why? How does that help? > > > May be if there is some way to serve each http server request with a > different tomcat service process (having a pool of tomcat processes). I > know that is not the tomcat philosophy, but I just wonder if it is feasible > via apache httpd and tomcat configurations. > > >> >>> If I have to run Apache HTTP Server which mechanism do I have to connect >> it with >>> tomcat? using Jk connector is the standard way? >> >> mod_jk, or mod_proxy_http or mod_proxy_ajp. >> >> >>> Do you recommend me to read >>> http://tomcat.apache.org/connectors-doc/reference/apache.html ? I've >> found >>> also http://tomcat.apache.org/connectors-doc/reference/apache.html but >> it >>> seems to be outdated. >> >> How is that related to your problem? >> >> >> p >> >>> Thanks for your response! >>> >>> Regards, >>> Hernán >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
