Server architecture best practice

[hvbtup]

Eclipse BIRT doesn't come with a server, so if you want to integrate BIRT into your own application, you have to find a solution for this yourself.

AFAIK there are 4 1/2 possible architectures:

1. Use the POJO runtime
2. Use the OSGI runtime
3. Use or adapt the WebViewer example
4. If your application is Eclipse RCP based, add the features to your product.

For prototyping only, you can use the runReport shell scripts to generate a report.
This is only for prototyping the application, because BIRT has a significant startup overhead. The shell scripts are very slow because this startup overhead is for every single report.
With the 4 other choices, report generation for multiple reports is much, much faster.

For differences between 1) and 2), see some of the comments in #792.

Regarding 3), the example is rather basic, but you can use it as a basis and add e.g. authentication, authorization etc just as you like, or you could develop a REST API or whatever.

The architecture 4) is only suitable for reports that are requested and shown directly in a desktop application.

Note that the engine is able to run multiple reports in parallel with multi-threading.

With option 1), it is also possible to run several processes (each possibly with multi-threading). I briefly described a reason for doing so in a comment in #792. But as a rule of thumb, you should start with a single multi-threaded process.

Since a single report may need a lot of memory depending on the kind of report, one should consider RAM usage, JVM memory parameters etc.

Which types of reports do need much memory?

There are two reasons:

1. The output (or an intermediate in-memory representation for it) is big, e.g. a PDF file with a lot of images/charts or an Excel file with 100k rows and a lot of columns.

2. BIRT needs to process a lot of data from the data source, in particular with sorting/grouping/aggregation functions. If you are using an SQL database as the only data source, consider performing this work in the DB if possible instead of BIRT - that's what SQL databases are made for.

RunAndRenderTask vs RunTask, then RenderTask

As a rule of thumb, RunAndRenderTask is much faster than separate tasks, but some features (e.g. page variables) require separate tasks. Furthermore, it is possible to create the same report in different output formats by calling RunTask, then RenderTask e.g. for PDF, RenderTask for DOCX.
Note that a rptdocument file (which can get quite big) is needed with separate tasks.

Memory considerations

You should specify -Xms and -Xmx memory parameters. 512m may be an appropriate amount, depending on the size of your reports (see above). For really big reports, 1024m or more may be necessary. Of course much higher values would require a 64 bit JVM.

Restrict the number of reports that run in parallel.

It might be a good idea to divide your reports in small, medium and big reports. You could then have something like a "memory cost" estimate for each kind of report and a "max total memory cost". E.g. a small reports costs 1 unit, a medium report costs 10 unit and a big report costs 200 units. Then if you define your max. total costs as e.g. 300 reports, a medium report can start only if the current memory usage is <= 290 units, and at most one big report can run parallel (start if current memory usage is <= 100).

A simpler model could be: Run max. 5 reports in parallel.

Consider using JVM memory parameters -XX:MaxHeapFreeRatio and -XX:MinHeapFreeRatio to give back unused memory from the JVM to the OS, if there are other applications running on the same machine.

@TheLaserNinja You wrote: "Used to be the biggest out of memory issue was with MaxPermSize, but I think that was done away with (and isnt an issue with the POJO runtime)"
Can you elaborate on that?

[wimjongman]

maxpermsize is no longer part of java

Also, we have a war file that can be dropped into tomcat and then you have the server.