it is overhead, but there really aren't too many options for the case given. If the process really will take a long time, having the process happen within the tomcat using the same JVM will introduce instability. In the long run, it is going to be hard to maintain a production system with such long running processes.
by spawning new processes, one can atleast get a big box with 8Gb of ram and kick multiple processes. I know of several applications that use the JMS model to handle heavy processes that take several minutes. This way, it allows the application to send a JMS message, the message gets routed to the big box for processing, when it is done, a message is sent back to the browser or webserver. Scaling this approach should be easier and is a matter of adding more servers to listen to the JMS topic. hope that helps peter On 11/21/05, BB Commish <[EMAIL PROTECTED]> wrote: > > Thanks Richard. I do require communication back to the user so I will take > a > look at JMS as you suggest. > > My concern with spawning jvms (as I mentioned in a reply to another list > member) is the additional overhead and the additional difficulty (as I > perceive it anyway) of deploying to a multi-machine environment. > > > >From: "Richard Mixon" <[EMAIL PROTECTED]> > >Reply-To: <[EMAIL PROTECTED]> > >To: "'Tomcat Users List'" <users@tomcat.apache.org> > >Subject: RE: Managing concurrent high memory processes > >Date: Fri, 18 Nov 2005 11:14:55 -0700 > > > >BB, > > > >It sounds like you are talking about what used to be called "batch > >processing". The workload is simply kicked off from a web request. Does > it > >(attempt) to return a request to the user? Are timeouts and issue? > > > >As far as available RAM - the obvious solution here is to move to a > 64-bit > >OS. We've been using AMD Opterons and SuSE Linux for high-memory Tomcat > >(JVM > >heap > 2GB) for a couple of years now. But I'm also running Windows XP > _64 > >on my desktop and its JVM seems able to take more than 2GB also. We have > a > >somewhat similar problem, in that we have to dynamically build an > in-memory > >"cube" of analytical data for charting and what-if exploration of > >results.But our reponses typically come back in between 15 seconds and a > >couple of minutes. > > > >Depending on how large your session is, you may not really want to use > >clustering - because your sessions are replicated across all or a subset > of > >machines. > > > >However simple load balancing with session affinity might help you scale > >your solution - either with multiple Tomcat's on a single machine or on > >separate machines. > > > >But ultimately, I think you are going down the correct path to consider > >spawning a separate JVM to handle this if it is a true "batch request". > >From > >what I know (please correct me if I'm wrong here) Tomcat is definitely > >optimized for handling larger numbers of "relatively" small requests. Its > >also much easier to tune Tomcat if you have a larger numbers of similarly > >sized workloads (requests). On mainframe transaction processing the > analogy > >was to an hour glass - if you mixed a few pebbles in with all of the > grains > >of sand, you ended up clogging up the works for everyone - not just > >yourself. > > > >This also lets you allocate CPU resources to these separate JVM as you > wish > >- if its all in Tomcat, you have much less control. > > > >Also, if communication has to occur back to a Tomcat user, you might > >consider using Java Messaging Service for this - at which point you > should > >look at Jboss or similar application server that has Tomcat and a JMS > >bundled together. > > > >Hope these thoughts are useful. > > > > - Richard > > > > > > > -----Original Message----- > > > From: BB Commish [mailto:[EMAIL PROTECTED] > > > Sent: Friday, November 18, 2005 10:50 AM > > > To: users@tomcat.apache.org > > > Subject: Managing concurrent high memory processes > > > > > > We have a Struts application running on Tomcat where a few > > > actions within the app can invoke processing that consumes > > > 300+ MB of RAM and can run for several hours. The issue is > > > how to make the application more scalable to accommodate > > > multiple concurrent 'high load' processes and also make > > > better use of servers with available RAM beyond the jvm > > > limits (we have used both Sun and JRockit jvms - typically on > > > Win2k3 as per customer requirements). > > > > > > Would Tomcat clustering/load balancing be suited to this > > > problem? Or is it more geared to managing high volumes of > > > requests rather than just dealing with certain high load > > > requests that need special attention? > > > > > > We have also considered spawning a separate jvm instance (or > > > retrieving from a pool more likely) to handle each high load > > > request with the 'normal' > > > requests being handled within the jvm running Tomcat. Is this > > > a feasible option? > > > > > > I will appreciate any comments. Thanks. > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
