Chrome-pdf : possibility to extend delay for downloadind all images ?

[MI53RE19]

Hi Jsreport team, first of all : Happy New Year!!

Here I come today as we are trying to migrate to chrome-pdf recipe, in our usage of jsreport we need to insert lot of dynamics image for each report, ( in average more than 200 images per reports arround less than 10Ko per image) however it seems that after arround 2min of generation, no more image are being downloaded (arround 4000+ images in this scenario) and the rest of image are replaced by an image icone with the alt text for the image.

Is there some config we could use to maybe increase the delay for all the images to be downloaded ? Our timeout is chrome_timeout=600000 and on the studio wait for idle network is set to true.

Thanks a lot for your help!!

[jan_blaha]

For completeness, what version of jsreport do you use? Do you see the same on the latest, with the puppeteer/chrome 1.11.0?

We use this puppeteer option
networkidle0 - consider navigation to be finished when there are no more than 0 network connections for at least 500 ms
https://github.com/GoogleChrome/puppeteer/blob/v1.11.0/docs/api.md#pagegotourl-options

So based on the documentation it should download all images, however, we haven't tested this so deeply.

[MI53RE19]

Hi Jan Blaha, thanks for the quick reply!!

We use the docker image jsreport-2.3.0-full for instance in a rancher environment, I asume this is the lastest version ?
if this can help the final document is 27.9Mb once downloaded

Indeed as per the documentation it should be loaded, so either there is a stop at some point that don't allow the download to be triggered, either it's the image source that would block more connections from jsreport for more than 500ms. I will check on the later option and try to come back by tomorow on that matter.

Thanks again!!

[jan_blaha]

I assume this is the latest version?

Yes, it is.

Ok, let's see tomorrow.

[MI53RE19]

Hi @jan_blaha,
Sorry for the delay... some unexpected event kept me away of computer for a while...
Anyway, I did look into it, and even switched back to wkhtmltopdf, I do observe a similar behaviour with the difference that the PDF is not outputed, only an error log which state that the content has been blocked Warning: Blocked access to file this log entry appears arround as many time as there were missing images in the chrome-pdf version.
Since it can be observed in another recipe I assume this is not proper to chrome-pdf and it would be on our end that something go wrong, for extra information all the images are from OVH Object Storage, which have for limitation the number of token it can distribute, (I don't think so but...) does Jsreport force the recovery of a new token in each transaction (as if it is not keeping any session data ) ?

Thaznks for your help!

[jan_blaha]

Ok.

does Jsreport force the recovery of a new token in each transaction (as if it is not keeping any session data )

We do nothing special. We just give to headless chrome the html and it will give us back the pdf.

There is API in chrome to intercept the requests. Maybe you could hook there and perhaps get some idea what is happening...

https://github.com/GoogleChrome/puppeteer/blob/v1.11.0/docs/api.md#pagesetrequestinterceptionvalue

It could end up somewhere here

https://github.com/jsreport/jsreport-chrome-pdf/blob/master/lib/conversion.js#L15

We will need to isolate the problem. Not sure how difficult will be to take the same images and put them to different image storage. Maybe it would crash as well when loading it from a file system. Then we would know we should blame chrome.

[MI53RE19]

Thanks a lot for your time,

I have to deeply apologize on my end as I finally figured out what was wrong :
the images url list (arround 8k) that was being used was not fully completed during the data generation (arround 4k only)
hence the recipe would call undefined instead of a proper https://link-to-img, which explain why no more
image where shown after a certain point in the PDF.
After fixing the data to contains proper url I could generate correctly the whole PDF with all the images as it should be.

The good point for us in this process is that we could find out about how chrome-pdf would handle this case and we are quite hapy about it since we still get a PDF at the end. The bad point is that it took too much time for both of us and I do apologize again for that.

Thanks a lot for your help!