tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lin <>
Subject Re: Managing concurrent high memory processes
Date Fri, 18 Nov 2005 18:02:38 GMT
sounds like you have a heafty reporting process, which loads a ton of data
and generates a large report. I definitely wouldn't recommend running these
processes within a single instance of Tomcat. You'll easily eat all the
available RAM and get OOME.

A better approach would be to off-load the process and use something like
JMS to route the message. If the process is generating a report, I would
recommend revisiting the design and implementation of that component. More
specifically, if you're running all sorts of multi-dimensional reports on a
large dataset that's 500K+ records, consider using an OLAP product. In many
cases, using MOLAP approach can reduce the processing time by 10x.

good luck


On 11/18/05, BB Commish <> wrote:
> 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:
> For additional commands, e-mail:

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