We have two pods running in production, each with one worker. Requests are distributed across these two instances. Each instance had processed approximately 6,000 requests; however, one instance became stuck while processing a PDF report, and we had to restart that pod. The report that caused the issue was generated successfully later without any problems.
We did not notice any memory or CPU spike during the time it was stuck.

Will chrome.strategy=dedicated-process cause more CPU and slowness compared to chrome-pool?

We faced an unusual issue. A report that generally takes around 30 seconds to generate did not generate. We did not see any 'Rendering request finished' log in the console. And all the subsequent requests started piling up in the queue.
Then, once hitting the reportTimeout, all the reports started throwing 'chrome pdf generation timed out'.

We had to restart the Pod. That pod was working fine for 15 days and processed around 6000 requests, but yesterday we started facing this issue.

Any idea what could be the reason here?

Hi @admin ,

Is this fixed in 4.11.0?

We have deployed jsreport (4.10.1) on a dedicated VM in the Production environment.
Configuration is as follows -
RAM: 32GB
CPU: 4 Cores
Architecture: x64
(non-containerised)
numberOfWorkers: 1

We keep getting Worker terminated due to reaching memory limit: JS heap out of memory once in a while. And it gets crashed and restarts after that.

Could you please let us know if we need to change any configurations or settings to avoid this issue?

Following is the error screenshot:

Let us know if you need any additional details.

We have some queries:

Could you please let us know the default heap size?

How many percentage of RAM should be allocated to heap?

If we have set only one worker then why are we getting heap size limit issue?

Do references held by previous renders get freed up after report rendering finishes?

Please let us know so that we will be able to monitor and set appropriate configurations.

We want to use jsreport-cli without installing it globally.

While running it for import from \node_modules\.bin folder, where jsreport was hosted as an application, but we faced the following error:

Although the "@jsreport/jsreport-cli": "^4.0.5" package is installed in the hosted application.

Couldn't find a jsreport installation necessary to continue with the execution of the command, make sure to install jsreport first.

Could you please guide us on how to perform the jsreport import-export activity without installing it globally?

Why don’t the other properties, like pdf margin top, get applied to this PDF?

I am unable to print a web page to PDF.

I want to convert https://tomastrajan.github.io/angular-ngrx-material-starter#/examples/stock-market to PDF. But it should wait for the page to complete visually. and then start the PDF generation. But seems it is not working.

Tried the following approach, but it times out.

Template:

Script:

Getting the following issue on reverting uncommitted changes. We are using MongoDB storage.
Any suggestions to troubleshoot this?

MongoServerError: Updating the path '@odata' would create a conflict at '@odata' at UpdateManyOperation.execute (/app/node_modules/mongodb/lib/operations/update.js:101:19) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async tryOperation (/app/node_modules/mongodb/lib/operations/execute_operation.js:203:20) at async executeOperation (/app/node_modules/mongodb/lib/operations/execute_operation.js:73:16) at async Collection.updateMany (/app/node_modules/mongodb/lib/collection.js:231:16) at async Object.update (/app/node_modules/@jsreport/jsreport-mongodb-store/lib/provider.js:236:19) at async persistChanges (/app/node_modules/@jsreport/jsreport-version-control/lib/main/versionControl.js:172:29)...

Thanks very much!

We are currently using async reports and sending multiple asynchronous requests to jsreport. As expected, jsreport adds these requests to its queue.

We’ve configured the reportTimeout setting to 45 minutes. However, we’ve observed that the timeout countdown begins as soon as the request reaches jsreport — not when the actual report execution starts.

Ideally, we were expecting the reportTimeout to start only once the report begins execution, rather than from the time it enters the queue. Could you please confirm if this is the intended behavior? If so, is there a recommended approach to handle longer queue times without prematurely triggering the timeout?

These async reports, as well as others in the queue, failed due to the 45-minute timeout being reached. The delay was caused by earlier async reports that were still pending in the queue.