@odirleiborgert yeah, I know that is kindof a work around but I find most reports render better with ChromePDF, although there are some instances where PhantomPDF does a better job due to rendering glitches in ChromePDF

@odirleiborgert you need to setup some sort of storage persistence for your reports, otherwise when the Docker container restarts (which Azure will occasionally do) you will lose you reports since by default it will be using filesystem provider which is the containers local filesystem which disappears along with the container on restart. We found this same issue (actually its not an issue, just needs correct config) we trialled using Azure Blob Storage which had reliability issues, also tried using the App Services persistent disks which also had stability issues, we found the most reliable (has not faulted in 6 months) was a MongoDb provider, we are using MongoDb Atlas account for $9/month and it works flawlessly

@jan_blaha
Ok, its something to do with 2.5.0 and Azure Webapp - I just updated the Azure Webapp to use my hacked "2.5.0 with Chromium 64" image which is the Docker file from 2.4.0 which NPM fetches latest JsReport - and this works fine, this image however does not include the MongoDb extension (+ a bunch of other extensions) since it logs only 31 extensions found at startup whilst the "-full" images find 49 extensions

@jan_blaha
This is weird, so I changed our Azure Webapp to use "jsreport/jsreport:2.5.0-full" as you suggested and removed all custom configuration (so removed MongoDb storage etc) - it still errors with that basic 2000 record report. However running the same Docker image locally with no custom configuration (so should be exactly same as the Azure Webapp) and it runs just fine, tested up to 511 pages without an issue.

Jan, Are you able to test on an Azure Webapp ?

@Kshitiz-Mittal
You can assign any valid JSON to request.data, so you can transform your query result and add new properties, alot of our reports are run by querying multiple datasets and then using JS to join and transform the data as needed, we primarily use HTTP OData requests to retrieve data but some reports are direct SQL using the 'mssql' NPM library

Hope that helps

Is there an easy way to change the version reported in the title bar?

We essentially have 2 versions :-

1. The JsReport version (currently 2.4.0)
2. Our custom Node modules (currently 1.9.3)

It would be neat to have the title bar read "JsReport 2.4.0-1.9.3"

@jan_blaha
Thanks for your quick responses :)

So we use JsReport a little differently to normal case I think, our Request Data (or sample Data) contains URLS of where to get the actual data from, the reports JS file will fetch the data and populate the Request.data context for the template to iterate over.

However this does not seem to be the problem as I was able to reproduce the error within our Docker test environment with just a Template and a large sample Data file (2000 records) side stepping the JS file altogether, reducing the sample Data to 1000 records and it runs fine - I have not found the breaking point

But when I copied these 2 files to the JsReport Playground I was unable to make it error, it produced an 86 page document (which is not huge I would think)

I have checked the Azure Webapp to make sure its not barfing on memory and its not, the VM is not huge but the memory graph shows its sits well under 10% usage always.

The following Dropbox link has the Template and Sample Data, although I doubt its of much use since the Playground renders it fine

https://www.dropbox.com/s/w7f59houwk2ao24/JsReport PDF Protocol Error.zip?dl=1

Below is our straight forward Docker file, from 2.5.0 it installs a config override + a few extra NPM modules and our helper Node module - the Puppeteer downgrade to 1.11.0 also shown

FROM jsreport/jsreport:2.5.0-full AS prod

COPY jsreport.config.json /jsreport/jsreport.config.json

WORKDIR /app
RUN npm i
request
request-promise
url
tough-cookie
@sendgrid/mail
webpack
round-to
puppeteer@1.11.0

COPY node_modules/virtualmgr /app/node_modules/virtualmgr

and the jsreport.config.json which essentially overrides some timeouts (this is not a timeout issue though)

{
"httpPort": 5488,
"allowLocalFilesAccess": true,
"store": {
"provider": "fs"
},
"blobStorage": {
"provider": "fs"
},
"templatingEngines": {
"timeout": 600000
},
"chrome": {
"timeout": 600000
},
"extensions": {
"scripts": {
"timeout": 600000
},
"html-to-xlsx": {
"timeout": 600000
}
}
}

I also tried using the Dockerfile from 2.4.0 as my "FROM" which built ok (and should have used Chromium 64 with latest NPM JsReport) but when I run it it errors with

2019-08-19T14:51:52.991144204Z 2019-08-19T14:51:52.915Z - info: Initializing jsreport@2.5.0 in production mode using configuration file: jsreport.config.json
2019-08-19T14:51:52.991177604Z 2019-08-19T14:51:52.924Z - info: Searching for available extensions in /app/
2019-08-19T14:51:52.991183504Z 2019-08-19T14:51:52.977Z - info: Extensions location cache not found, crawling directories
2019-08-19T14:51:57.726926059Z 2019-08-19T14:51:57.495Z - info: Found 31 extensions
2019-08-19T14:51:57.731570662Z 2019-08-19T14:51:57.686Z - error: Error occured during reporter init Error: options contain values that does not match the defined full root schema. schema validation errors: rootOptions.store.provider should be equal to one of the allowed values. allowed values: ["memory", "fs"]
2019-08-19T14:51:57.731588562Z at Reporter.init (/app/node_modules/jsreport-core/lib/reporter.js:141:15)
2019-08-19T14:51:57.731594162Z Error: options contain values that does not match the defined full root schema. schema validation errors: rootOptions.store.provider should be equal to one of the allowed values. allowed values: ["memory", "fs"]
2019-08-19T14:51:57.731599162Z at Reporter.init (/app/node_modules/jsreport-core/lib/reporter.js:141:15)

this appears to be something to do with my Azure environment variable of

"name": "store_provider",
"value": "mongodb",

which should be fine as this hasn't changed and surely mongodb is still supported ?

@jan_blaha Hmm, I dont see that Chrome version, I see

+21803 Executing recipe chrome-pdf
+22078 Converting with chrome HeadlessChrome/73.0.3683.103 using dedicated-process strategy
+24096 Running chrome with params {"printBackground":true,"margin":{}}
Error: Protocol error (Page.printToPDF): Target closed.
at Promise (/app/node_modules/puppeteer/lib/Connection.js:186:56)
at new Promise (<anonymous>)
at CDPSession.send (/app/node_modules/puppeteer/lib/Connection.js:185:12)
at Page.pdf (/app/node_modules/puppeteer/lib/Page.js:911:39)
at Page.<anonymous> (/app/node_modules/puppeteer/lib/helper.js:145:23)
at runWithTimeout (/app/node_modules/jsreport-chrome-pdf/lib/conversion.js:164:27)
at <anonymous>
at process._tickDomainCallback (internal/process/next_tick.js:229:7)

However if bash into my Docker image locally and do a

cat node_modules/puppeteer/package.json

it shows

"version": "1.11.0"

There must be more to downgrading Chrome than puppeteer - forgive me I know very little about how Chrome works with puppeteer or even what puppeteer is (perhaps I should Google that :) )

Cheers

@jan_blaha I upgraded to 2.5.0 yesterday and very quickly discovered this issue, I just tried downgrading Puppeteer to 1.11.0 as you suggested but it makes no difference - I will have to backdate to 2.4.0 for the time being, pitty as the new editor is much better

We need a simple endpoint that we can Ping on for health monitoring of our JsReport instance (running in Docker) - I can see there is a

/api/ping

GET method, however we also use Authentication and this means /api/ping is currently protected aswell which prevents Nodeping from monitoring as it does not have ability to specify authentication - any chance you could either add a new unprotected Ping endpoint or make the existing one unprotected.