To make sure we are compatible.

We need to update the mongo database versions and wanted to make sure there were no problems with this package.

Also, some versions are deprecated and driver 3.6x supports at max node 14

Hi,
I was checking the dependencies of the mongodb packages.

In here, jsreport-mongodb-store , i've notice the devDependencies of "mongodb": "3.6.5". (https://github.com/jsreport/jsreport/blob/master/packages/jsreport-mongodb-store/package.json)

Is it possible to upgrade it with a newer version? This is the compatibility table: https://www.mongodb.com/docs/drivers/node/current/compatibility/

Note that all version before 4.0 has reached the End of Life, as described here. https://www.mongodb.com/docs/manual/release-notes/

Thank you!

It works,
thank you for your explaination!

Thanks. Now, this jsreport-pdf-utils version correctly ping to 0.5.4, but the version of jsreport is still 2.11.0 that has the dependencies of bugged jsreport-pdf-utils 1.10.1.

Is it possibile to release a new tag of jsreport project with the dependencies of new version of pdf-utils?

I've tried your code, but in jsreport folder i've got the node modules of 1.10.1 related to jsreport, and in the jsreport-pdf-utils folder the right 1.11.1; the jsreport render still using the 1.10.1 with the 'broken' package directory.

Alternatively, is there a way to force the jsreport render to use a particular package version?

Hi,
this error occurs and has been already discussed on https://forum.jsreport.net/topic/2002/pdf-utils-with-custom-font-causes-undefined-name-error/6 but recently it has shown up again.

We suspect it was related to the package dependencies, as the fix has been released in the jsreport-pdfjs with at least the 0.5.3, actually released at 0.5.4; currently, the linked to the jsreport-pdf-utils into the 1.11.0 with 0.5.2 and the previously 1.10.1 has the 0.5.1 on dependencies. In those cases we've still check the error

In the latest tagged and released version of jsreport 2.11.0 (https://github.com/jsreport/jsreport/blob/2.11.0/package.json), there is a stricted dependencies to the 1.10.1 that cause some problem with the npm ci installation of packages, and the following tagged version (that fix the dependencies) is the 3.0.0 that we could not install yet on customers.

Can you please release a new version of js2 (2.11.1) with the dependencies updated, with jsreport-pdf-utils at 1.11.1 that has the dependencies of jsreport-pdfjs of 0.5.4? Or at least give us a procedure to follow in order to solve eventually other dependencies problem?

Thank you.

Hi, after a bit of examination we verified that the error was only by us, as we compiled with different versions of node and then the compatibility was skipped.

We found an error due to the lack of the handlebar package obtained from jsreport-handlebar, and initially, we thought it was due to the fact that in the js-handlebar package was declared only as devDependencies as you can see here:https://github.com/jsreport/jsreport-handlebars/blob/master/package.json

However, by retrying the process of package installation and dependency we found our own discrepancy and resolved. Thanks for the support and sorry for the inconvenience!

Jsreport 2.7.1 - Installing jsreport dependencies with NODE_ENV=production there is an error during startup due to jsreport-handlebars.

The problem is due to the fact that jsreport-handlebars has in dev dependencies handlebars, when it should be in normal dependencies.

This error doesn't appear if I use npm install, as the dev dependencies are installed

I would like to know what customizations in jsreport.config.json have you done except the mongo store?

This is the prod configuration:

{
  "certificate": {
    "key": "certificates/jsreport.net.key",
    "cert": "certificates/jsreport.net.cert"
  },
  "httpPort": 3001,
  "httpsPort": null,
  "logger": {
    "console": {
      "transport": "console",
      "level": "debug"
    },
    "error": {
      "transport": "console",
      "level": "error"
    }
  },
  "blobStorage": {
    "provider": "gridFs"
  },
  "store": {
    "provider": "mongodb"
  },
  "phantom": {
    "defaultPhantomjsVersion": "2.1.1",
    "numberOfWorkers": 2,
    "strategy": "phantom-server",
    "timeout": 60000
  },
  "allowLocalFilesAccess": false,
  "templatingEngines": {
    "strategy": "http-server",
    "numberOfWorkers": 4,
    "timeout": 1800000,
    "allowedModules": "*"
  },
  "chrome": {
    "timeout": 40000,
    "strategy": "chrome-pool",
    "numberOfWorkers": 4,
    "launchOptions": {
        "args": "--no-sandbox"
      }
  },
  "extensions": {
    "mongodb-store": {
      "uri": "<mongouri>",
      "prefix": "jsreport_"
    },
    "authentication": {
      "cookieSession": {
        "secret": "<secret>"
      },
      "admin": {
        "username": "<user>",
        "password": "<psw>"
      }
    },
    "scripts": {
      "allowedModules": "*",
      "timeout": 1800000
    },
    "sample-template": {
      "createSamples": true
    },
    "chrome-pdf": { 
    "timeout": 40000,
      "strategy": "chrome-pool", 
      "numberOfWorkers": 4,
      "launchOptions": {
        "args": "--no-sandbox"
      }
    }
  }
}

What version of jsreport do you use?

Those are the version of the packages:

    "jsreport": "2.6.1",
    "jsreport-chrome-pdf": "1.6.1",
    "jsreport-client-app": "^0.1.1",
    "jsreport-fs-store": "2.6.0",
    "jsreport-import-export": "1.4.0",
    "jsreport-mongodb-store": "1.2.2",
    "jsreport-pdf-utils": "1.5.2",
    "jsreport-phantom-pdf": "2.2.0",
    "jsreport-studio": "2.6.6",

Is it xlsx recipe or html-to-xlsx recipe you use?

The recipe is xlsx, with a custom xslx template used for every excel reports. For pdf reports we always use chrome-pdf (on jsreport settings you'll see phantom just for legacy reports on other customers, but it's not used here)

Do you run jsreport inside docker or it runs directly?

jsreport starts in a docker, with the starting script that just set some env variable and calls jsreport.init()

Do you persist outputs using reports extension?

No, we'll use an API request to create the report using jsreport, then it send back the b64 and we save the pdf in a different folder using a fs.writeFileSync(tmpName, (new Buffer(report, 'base64')).toString('binary'), 'binary');

Can't your code in script or templating engine memory leak? In case you use http-server strategy.

That was our first thought, in fact, we have worked considerably to make a general review for memory leak, but despite this we can not understand why this trend in memory. The strategy is included on the conf that is published before:

"templatingEngines": {
    "strategy": "http-server",
    "numberOfWorkers": 4,
    "timeout": 1800000,
    "allowedModules": "*"
  },

We could try to change the strategy to the dedicated-process to see if something change.

Thank you for your support; we will stay in touch with you for any further reports or updates.

Good morning, we're monitoring a jsreport installation as we've revealed some anomalies. In particular, the customer informed us that periodically the jsreport service was not responding for a certain period of time.

In fact, we verified that what was happening was a memory saturation. The execution times close to 100% expand exponentially causing a slowdown of the whole system.

We solved the situation momentarily by imposing a restart of the service every night, but especially as a result of a large daily load (there are about 100 users, with a pool of a thousand daily reports executed) or very heavy print runs the phenomenon may reoccur: we noticed that the memory starts to rise inexorably, even on the night where there is no work, however, there is an almost constant increase in memory.

The service is on a 4 core 8 GB ram machine, which instantiates two jsreports balanced with Round Robin with the mongodb store provider to avoid blocking the print queue in case of a print with a high runtime. We installed Grafana to monitor the situation, and this is an example where in the middle of the day there was a forced restart. The two attached graphs include the first one the garbage collector situation and the other one is the busy memory graph, which never seems to empty completely after printing.

What could it be?

Some of the peaks are near reports executed with xlsx recipes, whose template is an excel of about 200 columns for a thousand rows. The doubt that has come to us is that the template remains in memory even after the execution is finished and therefore keeps a part of the memory locked. However it can't be only this, as also the other pdf reports (with chrome-pdf templates) cause a slight increase of memory that then accumulates inexorably. We removed the various console.logs but we don't know what to try anymore.

Thank you for help.

garbage collector

jsreport memory