The Content Of This Document Process Takes More Than 60000 Milliseconds To Process

Posted June 23, 2010 at 7:08 PM by Ben Nadel

Tags: ColdFusion

Reader Comments

Do your embedded images have an Adobe RGB Color space? I've run into slowdowns in the past where the color palette was non-standard.
http://en.wikipedia.org/wiki/Adobe_RGB_color_space

One of the methods I've used to avoid timing out on large document generation is to create multiple smaller files and then merge them together. Prior to CF8 I was using the PDFTK toolkit to merge them all together:
http://www.accesspdf.com/pdftk/

@James,

We were thinking of using the multiple smaller documents with merging approach; but it was just for an internal project (ie. not billable), so we just opted for the quicker, smaller images. In the end, it actually turned out to probably be the better solution for what we were going for. BUT, it was frustrating not being to overcome the problem ... grrrr, HULK SMASH!

I'm not aware of the color space issue. I can say that the images were all JPG files exported from Adobe Fireworks, so hopefully they were compatible with other Adobe products.

I was going to suggest what you ended up doing.

You might be having image retrieval issues as well. Try using the file:// protocol for images vs http. That has helped me in the past.

@Mike,

I tried using file:///. I also tried using localURLs and relative pathing. It's just a general processing timeout I think. The "proofs of concept" worked fine with 30-40 images. But, once we beefed it up to several hundred images, it was just more than could be done in the given time.

If the images are spread across multiple pages, you can render the pages separately in separate documents and then afterward stitch all the documents together.

Additionally, you can drop down from cfdocument into iText, the open source pdf-rendering engine that cfdocument uses under the hood.

@Ben, I had a similar issue when I was trying to generate a very large PDF using cfdocument. The reason I found was the virtual memory size in that cannot be increased beyond 1.6 GB.

Note: This issue was in CF 7.

Workaround: Wrote a windows service to do the task.

Could you defer the processing by sending it to an asynchronous gateway?

@Jon,

Sending it to the worker process in a asynchronous gateway would also not do the trick I presume because of the file size. Please correct me if I am wrong.

For version "2" of this internal tool, we might get a bit more clever. But for now, we're just sticking with the smaller images as a proof of concept.

We had this very problem today and seemed to resolve itself with two small changes:

1.) All images must have relative pathing instead of absolute calls to "http://wherever..."; and

2.) Set the CFDOCUMENT attribute 'localurl="yes"'

Apparently, CFDOC will hang on absolute calls, so you may also need to check your CSS if used.

Hope this helps, and thank you so much for all you do.

~T

@Tim,

Yeah, the localUrl attribute definitely helps sometimes. We ran into a huge headache involved route-back issues a while back (arg that was a PAIN to debug). Our problem was simply the large number of images we wanted to include in the document. As we took some images out, it eventually started working (I'm talking like 30MB+ worth of images in the PDF).

Same here. No images. Just this:

<cfdocument format="PDF" localUrl="yes">
OK
</cfdocument>

And the same timeout error message.

We just had that problem and once we restarted coldfusion on the server the cfdocument problem stopped. I'm not sure if some cf memory filled up. Strange problem because my other cf pages were fine, it was just the ones with cfdocument wrapper.

I just had this same issue on a CF 7 environment. I was generating PDF reports that had several references to external resources: .css, .gif, .jpg. I replaced all relative paths to fullfy-qualified paths using the ExpandPath() method and all issues were resolved.
<div>
Example:
</div>
<div>
&lt;cfset fullSiteRoot = ExpandPath("/")&gt;
</div>
<div>
&lt;cfoutput&gt;
&lt;link src="#fullSiteRoot#css/global.css" rel="stylesheet" type="text/css" media="all"/&gt;
&lt;/cfoutput&gt;
</div>

I just created a forum post about this problem, we cut the load times from 60+ seconds to 1 second with the described fixes.

http://forum.hostek.com/showthread.php?493-cfdocument-timeout-fixing-timeout-problems-with-cfdocument

Hope this helps somebody.

Jon C.

@Victor, @Jon,

Awesome suggestion to use expandPath() for linked files. I haven't tested this, but that sounds like it would make a lot of sense.

Hello,

Did you find any reason for this issue? Since two day, any of my CFDOCUMENT "PDF" return the error "content....more than 20000 milliseconds..." on one of my server... My other server (PRODUCTION) is not having that issue, I checked the configuration and their are identical.

I'm desperately looking for a solution, too. My error message is really absurd.

"The content of this document process takes more than 0 milliseconds to process."

0 milliseconds? I use CF9.0.1 and I don't know where I can change "0 milliseconds" setting...

@Tim,

Removing the "http://..." and replacing with relative paths + adding 'localUrl="yes"' to the cfdoc-tag was the magic fix in my case.

Thanks for that!

Post A Comment

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment