dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Fri, Mar 20, 2009 at 10:14 AM, Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx>wrote:

> Dear all,
>
> We HISP Vietnam team meet a problem and need solution to solve. Currently
> DHIS2 of HISP Vietnam using report module to generate reports which created
> by BIRT report designer. On the March 19th, 2009 there was a training class
> for users to practice entering data and generating reports. The class
> includes 40 users work at same time in the program.
> Entering data values was fine. But when there are many users generate
> reports at the same time. The system suddenly become very slow and every
> user get the OutOfMemorry java exception when click in any button of the
> program. That time Tri has to restart the tomcat of server, the sistuation
> become better for 2 minutes, and the problem appear again when few users
> generate reports. This even affect to another users who doesn't generate
> report but entering data in the class that time.
> Tri has checked in database, there were many many transactions opened but
> weren't closed.
> After meeting to find the reason, we don't know about other reason except
> reports were designed by BIRT. May be we were wrong. We are looking forward
> your suggestions and consult to find out the right reason and solutions to
> solve. May be change another tool instead of BIRT, or correct the program or
> someway else. Dr. Trung requested us have to find the right solution before
> April.
> Please help us...
>

Increasing memory for Java/Tomcat  and the database is an option as Jason
points out. Please check the archives for info on this.

Otherwise, report generation processes are run sequentially and shouldn't
really give memory problems. A workaround could be to use the "view report
based on existing datasource" option when viewing the report (after the data
has been generated once), that is, skipping the aggregation process and view
the report based on what already exists in the database, should be less
resource demanding.

Will investigate this further.


Lars