One of the big fat questions lingering in the room with the latest release is (as usual):
Can I upgrade my existing BI-Server installation with the new reporting release?
Short answer: Yes.
With the latest bugfix release of Pentaho Reporting, we also had to upgrade both Kettle and Mondrian to their latest versions to make it run in the BI-Server 3.6.0 release. Due to the massive amount of work that went into Kettle 4.0, many of their APIs changed thus making it impossible to maintain backward compatibility.
Although we would love to see everyone migrate to BI-Server 3.6 immediately, the chances of that happening are fairly slim. Businesses seem to be a bit reluctant to change, once they have everything up and running. Heck, some people still run a 1.x release, which was released three days after the last dinosaurs died.
So how can I upgrade then? What will be the impact of this upgrade?
The upgrade is straight forward and can be done by deleting the following jar-files from the pentaho/WEB-INF/lib directory:
libbase-1.1.5.jar libdocbundle-1.1.6.jar libfonts-1.1.5.jar libformat-1.1.5.jar libformula-1.1.5.jar libloader-1.1.5.jar libpixie-1.1.5.jar librepository-1.1.5.jar libserializer-1.1.5.jar libswing-1.1.5.jar libxml-1.1.5.jar pentaho-reporting-engine-classic-core-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-hibernate-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-mondrian-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-olap4j-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-pmd-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-reportdesigner-parser-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-sampledata-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-scripting-3.6.0-GA.jar pentaho-reporting-engine-classic-extensions-xpath-3.6.0-GA.jar pentaho-reporting-engine-legacy-charts-3.6.0-GA.jar pentaho-reporting-engine-legacy-functions-3.6.0-GA.jar pentaho-reporting-engine-wizard-core-3.6.0-GA.jar
and replacing them with
libbase-1.1.6.jar libdocbundle-1.1.8.jar libfonts-1.1.6.jar libformat-1.1.6.jar libformula-1.1.7.jar libformula-ui-1.1.7.jar libloader-1.1.6.jar libpixie-1.1.6.jar librepository-1.1.6.jar libserializer-1.1.6.jar libswing-1.1.7.jar libxml-1.1.7.jar pentaho-reporting-engine-classic-core-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-hibernate-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-mondrian-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-olap4j-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-pmd-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-reportdesigner-parser-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-sampledata-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-scripting-3.6.1-GA.jar pentaho-reporting-engine-classic-extensions-xpath-3.6.1-GA.jar pentaho-reporting-engine-legacy-charts-3.6.1-GA.jar pentaho-reporting-engine-legacy-functions-3.6.1-GA.jar pentaho-reporting-engine-wizard-core-3.6.1-GA.jar
Note that the “pentaho-reporting-engine-classic-extensions-kettle” jar remains at version 3.6.0-GA. This ensures that the older Kettle 3.2 is used when running reports with a Kettle datasource.
To make the most of this upgrade, I also recommend to add a few new settings to the “pentaho/WEB-INF/classes/classic-engine.properties” file:
# # These settings control how pagination states are retained in the reporting # engine. For the server, it is safe to scale down the number of states to a # bare minimum. This reduces the memory footprint of reports considerably. org.pentaho.reporting.engine.classic.core.performance.pagestates.PrimaryPoolSize=1 org.pentaho.reporting.engine.classic.core.performance.pagestates.SecondaryPoolFrequency=4 org.pentaho.reporting.engine.classic.core.performance.pagestates.SecondaryPoolSize=1 org.pentaho.reporting.engine.classic.core.performance.pagestates.TertiaryPoolFrequency=1000 # # Disable several assertations and debug-messages, which are cool for testing reports # but slow down the report processing. You may want to enable them in your test system # but want to make sure that they are disabled in your production environment. org.pentaho.reporting.engine.classic.core.layout.ParanoidChecks=false org.pentaho.reporting.engine.classic.core.modules.output.table.base.DebugReportLayout=false org.pentaho.reporting.engine.classic.core.modules.output.table.base.ReportCellConflicts=false org.pentaho.reporting.engine.classic.core.modules.output.table.base.VerboseCellMarkers=false # Performance monitoring entries. Can generate quite a lot of text in the logs, so # keep them disabled for production environments org.pentaho.reporting.engine.classic.core.ProfileReportProcessing=false org.pentaho.reporting.engine.classic.core.performance.LogPageProgress=false org.pentaho.reporting.engine.classic.core.performance.LogLevelProgress=false org.pentaho.reporting.engine.classic.core.performance.LogRowProgress=false
With both the upgrade of the libraries and the new configuration settings, you should see a good performance boost.
Good post! Thanks! One question: Can this approach be followed to go from 3.5.0.GA.39705 to 3.6.0.GA.41813 as well?
3.5.0 is known to be deadly buggy. 3.5.2 is the bugfix release for that 3.5.x codeline, and you should upgrade your whole BI-Server to that release.
To upgrade your 3.5.0 release, you *have* to upgrade your BI-Server to at least 3.5.2.
I outright refuse to backport any changes to the plain 3.5.0-version, as there are more bugs there than just in the reporting engine and a public bugfix release of the BI-Server is publicly available on sourceforge.
For the next release of the reporting engine (3.7) we will prepare explicit backports of the reporting engine for the existing BI-Server 3.5.2 and BI-Server 3.6.0 installations. There will be no backport for the 3.5.0 installations, as they should finally upgrade to at least BI-Server 3.5.2.
Thanks Thomas! I guess this means we are partially screwed… but that motivates a clean install of 3.6.0 (but I guess after a 3.5.2 upgrade) – now it’s just a mission getting the content ported / re-developed.
Hi Thomas,
Do the same files work going from 3.7.0 to 3.8.1-RC1? I unwittingly saved some reports originally created with 3.7.0 in PRD 3.8.1, and they don’t work any more, so I need to upgrade the reporting engine on the server (but I’m very nervous about it – need everything else to keep working).
Thanks!
Dave.
No, in the same way a Office XP document does not work on a older MS Office system, a newer PRPT does not work on a old Report designer.
Whenever we add new features, these features get saved in the file. Once the report designer encounters a feature that it does not recognize, it will stop loading the file and report an error.
The general rule for most software is: Old documents run fine in new programs, but new documents cannot be used with old versions of the program.
Hi,
We’re working with a prd trunk version, that one: http://diethardsteiner.blogspot.com.es/2012/11/stylesheets-with-pentaho-report-designer.html
Do you know if is possible do the upgrade to a biserver 4.5 or 4.8?
Thanks in advance.
No way. The changes are numerous and mostly incompatible in nature. It is just not possible at all.
Hi,
We want to upgrade from 3.8 to 5.x. Is it possible to create a new installation and then migrate the old report s to new 5.x server.
Please guide.
Thanks
Sunny