Thanks for taking a look we are working on switching over to div's instead of tables that seems to fix the issue.
joshplaetzler
@joshplaetzler
Posts made by joshplaetzler
-
RE: Clickable links and page break avoid
-
Clickable links and page break avoid
I'm using some clickable links in my report to take the user to different parts of the PDF however after upgrading to 4.4 (from 2.11). Our links no longer seem to take you to where they should.
My current theory is if you use page break avoid the link doesn't seem to take in the extra space and brings you to where it would be if there was no page break.I was able to reproduce the issue here:
https://playground.jsreport.net/w/joshplaetzler/TcjfssFBAny idea on how we could get around this?
FYI: Tested this with just using divs instead of tables and didn't see the same issue so maybe that is the problem though we need to use tables throughout our reports and would like to avoid them getting split between pages when its not necessary.
-
RE: Getting an error when shortId is filled in
Wanted to give an update. We found the issue the client was sending the request with
Content-Type=application/octet-stream
and this causes that error to be thrown. -
RE: Getting an error when shortId is filled in
Logged in the server logs.
We are on version 4.4.0
Template store we use mssql, blob storage we use S3 bucket.
We are seeing this with non async call only, but not always, and we do use async as well.
We are setup using docker but not using docker workers extension.Here is a snippet of what we are doing we have our own endpoints configured and we have been editing the req and forwarding it on for jsreport to handle. We saw this once we upgraded to 4.4 which was just this week. We have tried but have not seen the error or been able to recreate it out side of our production env. If I succeed in doing so eventually I will edit that error to throw more info.
logger.info(`Retrieved Short ID ${shortid}`); // this logs with a valid shortId req.url = "/api/report"; req.method = "post"; req.body = { template: { shortid: "shortid" }, data: { ... // data the template will use }, options: { reports: { async: false }, "reportName": name } }; req.app.handle(req, res, next);
-
Getting an error when shortId is filled in
We are seeing this error:
Template must contains _id, name, shortid or content attribute
. And are trying to figure out why. We don't see it all the time and have been having trouble reproducing it out side our production env.https://github.com/jsreport/jsreport/blob/master/packages/jsreport-core/lib/worker/templates.js#L10
We log out the short_id right before sending this request to jsreport for rendering and it logs out without issue.
We are entering it into
body.template.shortid
but it is checkingreq.template.shortid
? I'm assuming this gets converted toreq.template.shortid
before this point as it does show up correctly when I tested it out locally. Do you know of anyway that even if the shortId is set inreq.body.template.shortid
, that it would still throw this error? It doesn't seem like that should be possible. -
RE: Async download queue?
@jan_blaha Thanks for adding the queueing for Async reports.
However, currently if you make an async request and all the workers are being used the request doesn't respond until a worker becomes available.
Is there a way for us to get the report to queue but respond right away rather than waiting for a worker to become available?
We have some large reports and if one of our servers gets bogged down with large reports there is a possibility of waiting 10-15min for a response from an async request.
I wasn't able to find any configuration that might help with this besides just setting the numberOfWorkers higher than I would like to.
-
Links in Mac Preview
Not sure if you guys are aware of the issue all ready but seems like links within PDF's don't work in mac preview (V4.3.1). Though they seem to work fine if the report was generated using 2.11. This isn't a big deal as they still work in the browser, but thought I would bring it up here in case some one else runs into the same issue.
To recreate the issue: Downloading from https://playground.jsreport.net/w/jan_blaha/CoLyzY~M or https://playground.jsreport.net/w/admin/akYBA4rS
Open PDF in Mac Preview and click on link does nothing.
If there is a way to get links working on Mac Preview would appreciate it.
Thanks.
-
RE: Docker performance issues
We did figure out the performance issue for us was using headless: new, with this turned on we saw consistently slower report generation times. Though some of our largest reports with lots of canvases and images still won't generate it is a step in the right direction.
@msageryd Thanks for the info. We don't actually use childTemplate at all we utilize pdf-utils as we have different page orientations we need to support.
-
Docker performance issues
We're in the process of upgrading jsreport from version 2.11 to 4.3.1 and are experiencing some performance issues. While HTML script execution within our jsreports has sped up, the overall time to generate PDFs has significantly increased. This slowdown is particularly pronounced with our larger reports but is noticalbe with some reports that use to take <1min not take about 2 min.
In our AWS lab environment and on Docker Desktop, we've observed a consistent performance degradation of 25-50% compared to running outside Docker, where version 4.3.1 is noticeably faster.
Our Docker configuration uses a custom Ubuntu 22.04 base image tailored with specific dependencies needed for our projects. We initially used the full jsreport Dockerfile and made necessary modifications to integrate our base image. Additionally, we tested with the default jsreport Dockerfile, not using our custom Ubuntu image. Our test servers are well-resourced with more than enough memory and cpu.
We have tried various Chrome strategies, worker configurations, and numerous argument flags. We've also explored other configuration options as suggested in discussions like this one: https://forum.jsreport.net/topic/3055/jsreport-performance
Could anyone provide insights or suggestions on what might be causing these performance issues within the Docker container? Any advice would be greatly appreciated.