Posts made by joshplaetzler

Looks like this issue is resolved in v4.6.

We seem to be running into an issue and was wondering if its something you have seen before. we have some fairly large reports we are talking 1000+ pages that have a TOC (render twice approach). But these larger reports started timing out. we increased the time out and the one report took 1.5 hours to finish and when we removed the TOC it took 6 min.

We are using v4.4.0 at the moment, and think this started happening when we upgraded from v2.11. Appreciate any insight you might have on this. Maybe we need to update how we are handling the TOC.

This seems to be an issue with chromium v126:
https://github.com/puppeteer/puppeteer/issues/12601

OK thanks we will change that and see if it helps.

We are seeing the same issue in v4.5 when we tested this out v4.4 seems to work correctly.

We are getting the following error in our prod env after upgrading to jsreport 4.4.

Failed to clean up old reports Transaction (Process ID 2) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. code=EREQUEST, originalError=Error: Transaction (Process ID 2) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction., name=RequestError, number=1205, lineNumber=1, state=45, class=13, serverName=***, procName=, precedingErrors=, stack=RequestError: Transaction (Process ID 2) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

We have multiple instances of jsreport running on ubuntu in docker containers, we use mssql as our store and blobStorage is aws s3 buckets.

Error started 30days after we upgraded to 4.4 i'm assuming cause our cleaning threshold is 30d
Clean up configuration:
"cleanInterval": "3h",
"cleanThreshold": "30d",
"cleanParallelLimit": 10

Also we don't see the error in our labs env but there are a lot less reports generated there than in our prod env.

Any idea why we might be getting this when the reports cleanup happens? Could lowering the ParallelLimit help?

Thanks for taking a look we are working on switching over to div's instead of tables that seems to fix the issue.

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/TcjfssFB

Any 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.

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.

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);

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 checking req.template.shortid? I'm assuming this gets converted to req.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 in req.body.template.shortid, that it would still throw this error? It doesn't seem like that should be possible.

@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.

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.

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.

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.

Hey JSReport Team,

Just wondering if there is any built in sanitization that can be used for sanitizing data used for a template that might have malicious html or javascript, particularly to prevent Server-Side XSS. Or is this something we would need to be sure to implement on our own in the script or handlebars to prevent.

Thanks

Yeah I don't see why it would either. We have two servers deployed to an AWS ECS. We are aware of the issue with them both having their own /app/data/storage and are working on a solution that will work for us. In the mean time we just make the request until the load balancer points to the correct server. I've checked both servers for the files as well as requested the file more than enough times to hit the correct server. Like I said the smaller files we have not had any issues with and the larger ones have been consistently an issue since we upgraded to 2.10.

I will setup the 2.11 when I get a chance and see if I see the same thing.

Thanks.

I'm experiencing an issue with our server running 2.10. (this setup uses the docker image jsreport/jsreport:2.10.0-full ) I have about three reports being generated async that range from 65-75mb that seem to finish, status changes to report ready, but the file does not seem to get saved and you can not retrieve the file through the api. Our store.provider is mssql and the blobStorage.provider is fs. Running smaller files (< 50mb) seem to have no issues and get saved to the expected folder, and am able to retrieve without issue.

I've been able to run the same code on my local computer (mac) using the sotre.provider: fs and calling it through the api async.

Error I see:
ENOENT: no such file or directory, open '/app/data/storage/1a4d4cd3-f9c7-4285-b7c4-29cc69aa81b8.pdf', stack: Error: ENOENT: no such file or directory, open '/app/data/storage/1a4d4cd3-f9c7-4285-b7c4-29cc69aa81b8.pdf'

Any help with this would be greatly appreciated.

Thanks sorry. I see it now was using it on an older version of Jsreport tried on a newer one and its there.