I'm generating pdf's with images autoscaled via imagegen but when exporting a pdf with some images not yet cached by imagegen some images doesn't show up in the pdf. Trying one more time (at which time imagegen has already cached all the images) then they all come in.
I'm assuming this is related to some sort of timeout on the image fetch and wonder if this timeout can be adjusted so I can make the pdf creator a bit more patient allowing imagegen to be done delivering the image?
I guess I agree with you and jumping to that conclussion was premature. So let me focus on what I experince: We use imagegen everywhere on the site and we have never seen an image not loading. We now also use imagegen to scale images inserted in pdf's with pdf creator. The image originals are fairly large at 4-5mb. When opening a pdf with images which haven't been used in pdf's before (and therefore haven't been processed and cached by imagegen) some doesn't appear - often about 75% is missing. When openeing the same pdf again (now assuming imagegen can deliver all images from it's cache) they all show fine.
So let't ignore the timeout thesis. Then the question remains - what could be the cause for this behavior which is of course undesired? Any ideas? I'm aware we could find ways to precache all the images which would likely work but seems like a quite dirty workaround.
I would start by looking at your IIS logs - you should have both the image requests and the PDF creator request in there. I'd check the HTTP response status of the image requests to ensure that they are 200s. If they are then I think your idea that PDF creator doesn't wait long enough may have some legs.
If the imagegen requests are completing after the PDF request this would further back up your idea.
The 9 images used for the pdf is called through imagegen and returned with code 200. The resulting pdf only includes the two last images and as can be seen above they are the ones with a "sc-win32-status" of 0 where the missing ones has 64. Also the "time-taken" are the lowest for those two images.
Doing the same request again now with cached imagegen images gives this result in the log:
Note that "sc-win32-status" is now 0 for all and "time-taken" is considerable lower for all (not suprising considering that they are now delivered from file cache).
Found a setting in the underlying PDF rendering engine docs:
WebRequestTimeoutMs
When an external-graphic element
specifies an image is retrieved from a
web server, this is the timeout used for
the call to the web server. Units are
milliseconds.
Default is 300 ms - I could extend this in code but would require a new release of PDF creator. I'd be happy to include this. Are you a customer? What are your timescales like on this project.
I'm a little suprised by the default of 300ms as I would think time-taken is milliseconds and the log indicates success with a value of 1513 for the last image in the first (failed) pdf rendering. Anyway - if we should be on the safe side with the the kind of time-taken values seen above I would think a timeout of 10000 would be necesseary.
I'm a customer - we are live at www.ai.dk (pdf export is in a secured area so I can't give you a link to that feature of the site - at least not here) - so we are dealing with a production bug which luckily do have a workaround (try again) but would still be good to address asap. What should we expect?
Thanks in advance for the solution and also thanks for your rapid replies to requests here already :-)
I agree that it's not a bug in pdf creator (or the underlying engine) - it's an environment setting which we didn't know of - we do now. The bug I refer to is what our customer experience in their live soltion: PDF's missing images - from that point of view it seems buggy :-)
A way to set the timeout would be ideal - thanks. We'll be awaiting your update.
We could get you a patch quicker that had a harcoded higher timeout in - it will take a while to work out how to pass in the setting from the template. Let me know if that is of interest and how high you would like the timeout....
That would definately be welcome. Let's go for 15000 then to be on the safe side of the safe side so we avoid having to ping you again. Thanks. I assume you have my email from the license associated with ai.dk an can post it to me there.
Images inserted via imagegen is missing on first try
Hi,
I'm generating pdf's with images autoscaled via imagegen but when exporting a pdf with some images not yet cached by imagegen some images doesn't show up in the pdf. Trying one more time (at which time imagegen has already cached all the images) then they all come in.
I'm assuming this is related to some sort of timeout on the image fetch and wonder if this timeout can be adjusted so I can make the pdf creator a bit more patient allowing imagegen to be done delivering the image?
/Pau
Hi Pau,
I don't believe PDF creator would time out requesting images - or if it did the whole process would time out.
Hi Darren,
I guess I agree with you and jumping to that conclussion was premature. So let me focus on what I experince: We use imagegen everywhere on the site and we have never seen an image not loading. We now also use imagegen to scale images inserted in pdf's with pdf creator. The image originals are fairly large at 4-5mb. When opening a pdf with images which haven't been used in pdf's before (and therefore haven't been processed and cached by imagegen) some doesn't appear - often about 75% is missing. When openeing the same pdf again (now assuming imagegen can deliver all images from it's cache) they all show fine.
So let't ignore the timeout thesis. Then the question remains - what could be the cause for this behavior which is of course undesired? Any ideas? I'm aware we could find ways to precache all the images which would likely work but seems like a quite dirty workaround.
/Pau
I would start by looking at your IIS logs - you should have both the image requests and the PDF creator request in there. I'd check the HTTP response status of the image requests to ensure that they are 200s. If they are then I think your idea that PDF creator doesn't wait long enough may have some legs.
If the imagegen requests are completing after the PDF request this would further back up your idea.
Here is the IIS log entries which are recorded when generating one of the PDF's (after deleting all imagegen cache images):
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2012-11-25 15:17:53 10.108.7.69 GET /imagegen.ashx image=/media/52317/Projektbillede.jpg&width=866&height=433 80 - 174.129.231.134 - 200 0 64 3088
2012-11-25 15:17:55 10.108.7.69 GET /imagegen.ashx image=/media/52272/01.jpg&width=866&height=433 80 - 174.129.231.134 - 200 0 64 4508
2012-11-25 15:17:57 10.108.7.69 GET /imagegen.ashx image=/media/52277/02.jpg&width=416&height=208 80 - 174.129.231.134 - 200 0 64 3759
2012-11-25 15:17:58 10.108.7.69 GET /imagegen.ashx image=/media/52282/03.jpg&width=416&height=208 80 - 174.129.231.134 - 200 0 64 3385
2012-11-25 15:18:00 10.108.7.69 GET /imagegen.ashx image=/media/52287/04.jpg&width=416&height=208 80 - 174.129.231.134 - 200 0 64 3166
2012-11-25 15:18:01 10.108.7.69 GET /imagegen.ashx image=/media/52292/05.jpg&width=416&height=208 80 - 174.129.231.134 - 200 0 64 2074
2012-11-25 15:18:03 10.108.7.69 GET /imagegen.ashx image=/media/52297/06.jpg&width=866&height=433 80 - 174.129.231.134 - 200 0 64 1918
2012-11-25 15:18:04 10.108.7.69 GET /imagegen.ashx image=/media/52302/07.jpg&width=416&height=208 80 - 174.129.231.134 - 200 0 0 1107
2012-11-25 15:18:05 10.108.7.69 GET /imagegen.ashx image=/media/52307/08.jpg&width=416&height=208 80 - 174.129.231.134 - 200 0 0 1513
2012-11-25 15:18:07 10.108.7.69 GET /eksport/projekter/projekt-pdf/ projekt=1564 80 - 212.242.114.55 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_6_8)+AppleWebKit/534.57.2+(KHTML,+like+Gecko)+Version/5.1.7+Safari/534.57.2 200 0 0 25896
Found a setting in the underlying PDF rendering engine docs:
WebRequestTimeoutMs
When an external-graphic element
specifies an image is retrieved from a
web server, this is the timeout used for
the call to the web server. Units are
milliseconds.
Default is 300 ms - I could extend this in code but would require a new release of PDF creator. I'd be happy to include this. Are you a customer? What are your timescales like on this project.
There you go - makes sense :-)
I'm a little suprised by the default of 300ms as I would think time-taken is milliseconds and the log indicates success with a value of 1513 for the last image in the first (failed) pdf rendering. Anyway - if we should be on the safe side with the the kind of time-taken values seen above I would think a timeout of 10000 would be necesseary.
I'm a customer - we are live at www.ai.dk (pdf export is in a secured area so I can't give you a link to that feature of the site - at least not here) - so we are dealing with a production bug which luckily do have a workaround (try again) but would still be good to address asap. What should we expect?
Thanks in advance for the solution and also thanks for your rapid replies to requests here already :-)
/Pau
That was a typo - i meant the default value is 3000 :)
I wouldn't describe it as a bug - the rendering engine behaves as designed and described in the documentation.
We will attempt to give you a patch release during the week - basically we'll allow you to set an http header in your template specifying the timeout.
3000 makes more sense :-)
I agree that it's not a bug in pdf creator (or the underlying engine) - it's an environment setting which we didn't know of - we do now. The bug I refer to is what our customer experience in their live soltion: PDF's missing images - from that point of view it seems buggy :-)
A way to set the timeout would be ideal - thanks. We'll be awaiting your update.
/Pau
We could get you a patch quicker that had a harcoded higher timeout in - it will take a while to work out how to pass in the setting from the template. Let me know if that is of interest and how high you would like the timeout....
That would definately be welcome. Let's go for 15000 then to be on the safe side of the safe side so we avoid having to ping you again. Thanks. I assume you have my email from the license associated with ai.dk an can post it to me there.
Thanks again.
/Pau
I got the hotfix and it solved the problem - thanks :-)
/Pau
is working on a reply...