Debugging Chrome/Chromium for graphical rendering of reports

Issue:

The TIBCO JasperReports® Server Administrator Guide documents the configuration required to use Chrome/Chromium for exporting graphical Chart reports and exporting dashboards. However there are no additional information on how to debug Chrome/Chromium whenever there are issues. 

What additional debugging can be performed to aid the user in circumstances where there are issues with exporting a Chart report (such as exporting to PDF format) or rendering of dashboards ?

Solution:

This article assumes that the TIBCO JasperReports® Server is properly configured to use Chrome/Chromium for Charts generation and exporting dashboards. If it is not yet configured, please refer to TIBCO JasperReports® Server Administrator Guide section "Configuring a JavaScript Engine for Graphical Report Rendering".

1> Checking the TIBCO JasperReports Server log file

Whenever there are issues with exporting of a graphical chart report, the user may see an error displayed on the browser similar to:

"There was an error on the server. Try again or contact site administrators. (Error UID: b3d56064-9574-4dac-9636-ffcb9d103384)"

The error message is generic but there is a UID code that can be correlated to the same UID code in the jasperserver.log file. This is the main server log file that resides in the directory..WEB-INFlogs. 

Correlating the UID code in the log file can lead the user to the full stack trace such as below:

2021-08-06T07:10:50,105 ERROR ErrorPageHandlerAction,https-jsse-nio-443-exec-6:118 - Error UID b3d56064-9574-4dac-9636-ffcb9d103384 net.sf.jasperreports.engine.JRRuntimeException: com.github.kklisura.cdt.services.exceptions.ChromeServiceException: <message of error>
    at com.jaspersoft.jasperreports.highcharts.charts.ChartPdfHandler.exportElement(ChartPdfHandler.java:45)
    at net.sf.jasperreports.engine.export.JRPdfExporter.exportGenericElement(JRPdfExporter.java:4141)
...
Caused by: com.github.kklisura.cdt.services.exceptions.ChromeServiceException: <message of caused by error>

The error message in the "Caused by:" of the stack trace may be sufficient for the user to be able to determine the cause and thereby take the necessary actions to resolve the problem. 

2> Setting additional logger components

If the above check does not lead to a solution, then more granular information can be captured in the same jasperserver.log file. This can be done by adding the following logger components to DEBUG in the Server Settings -> Log Settings page of the TIBCO JasperReports® Server (logged in as 'superuser') :

com.github.kklisura.cdt.launch = DEBUG
com.github.kklisura.cdt.services.impl = DEBUG
net.sf.jasperreports.chrome = DEBUG

Note: This is an on-the-fly change that does not require a restart of the application server.

Once these components are set, after reproducing the issue again, the jasperserver.log captures more verbose logging such as :

2021-08-10T14:45:28,284 DEBUG WebSocketServiceImpl,pool-14-thread-4:90 - Connecting to ws server ws://localhost:49312/devtools/page/644C28D808DF054A48FFCD4B6D66E662
2021-08-10T14:45:28,366  INFO WebSocketServiceImpl,Grizzly(2):98 - Connected to ws server ws://localhost:49312/devtools/page/644C28D808DF054A48FFCD4B6D66E662

The extra level of information is helpful as it exposes not just the events occurring but also the web socket port/s that is used for the report export since the port number can vary.

Depending on what the actual error message is but the extra level of information can be the clue to pinpoint any server port restrictions involving firewall or third party security applications affecting the operations in the background. For example, the administrator may want to test the websocket port using "telnet localhost <port>" on the server to see whether the port is active. 

Aside from the websocket port/s, there are other events captured which can also be helpful in understanding the behaviour and hence the point of failure.