The Content Of This Document Process Takes More Than 60000 Milliseconds To Process
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
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>
<cfset fullSiteRoot = ExpandPath("/")>
</div>
<div>
<cfoutput>
<link src="#fullSiteRoot#css/global.css" rel="stylesheet" type="text/css" media="all"/>
</cfoutput>
</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!
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)