Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at NCDevCon 2011 (Raleigh, NC) with:

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

By Ben Nadel on
Tags: ColdFusion

I was recently using CFDocument to create a rather large PDF with tons of embedded images when I got the following ColdFusion error:

The content of this document process takes more than 60000 milliseconds to process. This timeout value is obtained from the request timeout set in the ColdFusion Administrator.

At the time, I was already overriding the request timeout with a CFSetting tag (I had anticipated this page taking a while to run); this override, however, did not seem to affect the CFDocument tag's performance. I then went into the ColdFusion administrator, as the error suggested, and increased the core request timeout settings. This also did not appear to help the matter. It seems that there is an upper limit to the amount of time that the CFDocument tag will be allowed to run before it is forced to timeout. I did a whole bunch of Googling on this and asked around and could not find anyway to overcome this limitation.

I am posting this here not with answers, but with the hope that someone might drop by with a comment and tell me how to fix this. I have since changed my strategy to using smaller images. But, if I should ever need to create a very large PDF, I would love to know how to overcome this hurdle.

It should be noted that I am running on ColdFusion Standard, so there might be some programmatic throttling that is not present in the Enterprise edition of the ColdFusion application server.




Reader Comments

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

Reply to this Comment

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.

Reply to this Comment

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

Reply to this Comment

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.

Reply to this Comment

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

Reply to this Comment

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

Reply to this Comment

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.

Reply to this Comment

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

Reply to this Comment

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

Reply to this Comment

Same here. No images. Just this:

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

And the same timeout error message.

Reply to this Comment

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.

Reply to this Comment

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>

Reply to this Comment

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

Reply to this Comment

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.

Reply to this Comment

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

Reply to this Comment

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

Reply to this Comment

I realize this is an old thread; however I had an application running in production with no problems for over two years... all of a sudden daily errors seem to be coming from cfdocument. (See stack trace below) 2 page pdf - no images - no links - no included files (css). Any thoughts?

coldfusion.document.DocumentProcessTimeOutException: The content of this document process takes more than 60000 milliseconds to process. at coldfusion.tagext.lang.DocumentSectionTag.doAfterBody(DocumentSectionTag.java:446) at cfdsp_print_request2ecfm333730141.runPage(D:\CFAPPS\ba11incd\cfm\dsp_print_request.cfm:166) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:231) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:416) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:360) at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48) at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40) at coldfusion.filter.PathFilter.invoke(PathFilter.java:94) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38) at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62) at coldfusion.CfmServlet.service(CfmServlet.java:200) at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89) at jrun.servlet.FilterChain.doFilter(FilterChain.java:86) at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42) at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46) at jrun.servlet.FilterChain.doFilter(FilterChain.java:94) at jrun.servlet.FilterChain.service(FilterChain.java:101) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
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.