Using async call, ping url give error until file exist
-
Hi Jsreport team,
So I'm here to ask you some clarification regarding this choice.
following the doc I achieved the wanted behaviour with async request, however I'm suprised that the "ping" request return a500error message rather than a200with "not ready yet" instead
because basicaly the /status page is to tell you if the report is ready or not.I really personnaly think it would be better to have a successful answer with just the content telling you the situation rather than having that
500.Also this could allow for better/easier error handling on client side if they do request a document that fail during rendering, as the error code could be used to point what went wrong instead.
What is your opinion on that matter? =)
-
You talk about this feature?
https://jsreport.net/learn/reports#asyncI don't see we would return "not ready yet" somewhere. We also return 500 if the report cannot be found at all, not when the rendering is not finished
https://github.com/jsreport/jsreport-reports/blob/master/lib/reports.js#L88
-
Thank for answering!
Sorry if I wasn't clear enough. But yes this is what I was talking about.
The thing is that it does throw a big error message into jsreport server console (which is probably normal then) with all the path details.
but then I did had some time out error during those test (trying to do some heavy load run) and I couldn't catch nor see which report actually failled in the process, ans so the ping system could not stop from pinging despite the fact that the report generation had failled
-
Can you print the stack traces and messages? There shouldn't be errors in the normal situation. Only 200 and 201 status codes.
-
Sure here is the console screenshot and terminal:
-
Cannot replicate this so far, works for me normally without errors.
Does this happen for you also if you run just single report without parallel execution?
Do you use default fs template store?
Could you post here whole or critical part of log.txt?The url served to you should always include the existing report id, because the item is created before the response is sent to you. I don't see a place for mistake in the code so far.
-
Hi!
Okay so I did try generate only one document and it worked, I even pushed to 5 at the time and it worked too, arround 10 and systematicaly I would get that error.
if by log file you mean the error.log, then this one stay empty after encountering such behaviour I'm affraid :( (did delete the file and restarted jsreport to make sure it would be accurate)
if you ask for the reporter.log then again, the error is not logged in it, it seems it show only on the console so far. Since it's a bit long (+1000 lines) could I send it to you by mail?I do use the default template store also.
I'm starting wondering if this would be related to the fact that I didn't set a limit to the wkhtmltopdf workers and since I'm running (for now) test on a local machine with 'low' performance (compared to a proper dedicated server) could it be that the issue might be hardware related?
my machine spec are the following (if this can help you in the investigation):
Windows 7 Pro SP1 x64
4Gb RAM
AMD Phenom 9650 Quad-Core 2.30GHz
-
Thank you for further info. It seems it is a concurrency issue. I'll have to try to run some kind of parallel test on it.
Please email me the reporter.log to my email.I'll try to find a time and look at this issue.
-
Thank you again for your valuable inputs. I found the problem was actually in our permissions handling.
Could you please apply this patch to your installation and try it again? The fix would be then part of the next jsreport release.
https://github.com/jsreport/jsreport-reports/commit/c630630dd5bf6cc1806e88af22a76e6065f02096
-
You're welcome!
I did apply the patch and it's working like a charm now (get only 200, 201 and sometime 304 codes)
(did the test with 200 reports requests in parallel)
A big thank you for your help and time!!
-
Thank you for confirmation. You can expect the fix in the next jsreport hotfix.
