i found two differences between my service vs runing via the Studio UI.
After remarking code I have now concluded that pdfPassword breaks my hrefs.
Is this a bug?
I think I'm loosing hair over this..
I can embed hrefs in my PDFs without problem. They render fine on my production server at AWS Fargate. The hrefs works fine when I download the report.
If I embed hrefs for svg elements it seems to break all hrefs (even the ones not in svg). I'm not sure if this is the cause, though.
If I run the exact same json dataset on the exact same server via Studio, all hrefs works fine.
Is there something href related going on under the hood when reports are rendered "headless", i.e. without using Studio?
Postman seems to have the same problem:
https://github.com/postmanlabs/postman-app-support/issues/10338
I'll do that and get back to you. Thanks.
Thanks.
I'm taking care of the error codes at my client, so I'm sure that I didn't get one.
Quite worrysome that a container can hang without ECS discovers this and kills the container.
I have never seen this behaviour before. Maybe (hopefully) I won't see it again. I cannot recreate it, so I'll drop this.
I have had memory reclaim problems at my jsreport server for several years. The last time I digged into this problem, I "closed the case", after discussion with Jan. We thought that the memory in the graph would be automatically garbage collected when needed. But I don'think this works very good.
This has seldom been a problem since I'm queing all my report requests on a separate server, which feeds jsreport with jobs. Failed reports will eventually be rendered and the client probably won't notice the delay caused by the jsreport restart.
When jsreport is fed with very large reports (json dataset 20-40 MB) this gets troublesome.
This memory chart shows the memory consumption for tre consecutive large reports. The third report crashes my Fargate container.
I'm running the official 2.11 Docker image.
Strategy is "in-process".
The machine is a 2vCpu 5GB Fargate container.
How should I investigate this further?
I'm assuming that this is some kind of out-of-memory crash, but I don't know since the crashed machine does lot leave any evidence after the crash.
Wow, this seems like a really nice release. When do you think you'll release it to production? (edit: never mind.. I'll be patient =)
//Michael
Occationally JSReport can't cope with our reports. We have probably had at least one automatic restart of our Amazon Fargate container per month. But today, there was no restart. JSReport seemed fine, but it had stopped working on our report requests.
Normally when this happens, the service is restarted and all is fine afterwards. The only difference I can think of is that we upgraded from 2.10 to 2.11 a couple of months ago.
I collect the json we use for report rendering in a log, so I was able to use the exact same json as the failed report in my dev environment. I got a popup telling me that the data was to large and I need to change inputRequestLimit.
I'm suspecting that this popup is "showing" in my production container and prevents the service to be restared. Could this be the case?
Actually, I'm not sure if we have had this "too large dataset" problem before. How is the server supposed to react to this? I would at least need to get back an error to my client (the client is another Fargate container which works the report queue)
//Michael
This post deleted (was previously a bug report, but there is no bug).
Sorry, I read an old error from the error log.
I have tested the following:
ownerPasswordpasswordpdfSignpdfSign AND lock with ownerPasswordpdfSign AND lock with ownerPassword AND protect with passwordEverything works in various combinations.
Great work, Jan!
edit: all tests where done via the API, i.e. I have not tried to do this from within Studio.