Why am I not able to get full 60 second CPU time in @future method with getContentAsPDF()

Question

I'm trying to generate a PDF, and in normal Apex execution the function is haulted due to CPU timeout (exceeding 10 second execution time).

So I tried using @future annotation to use Asynchronous Apex since with Winter '16 we can uyse getContent() and getContentAsPDF() in Asynchronous Apex.

My code looks like this:

public void makePDF() {
    MyClass.generatePDF(con.getId(), arecord.Name);
}

@future(callout=true) 
public static void generatePDF(Id recId, String recName) {
    PageReference pageRef = Page.StmtPDF;
    pageRef.getParameters().put('stmtid', recId);
    Blob b = pageRef.getContentAsPDF();
    Attachment att = new Attachment();
    att.Body = b;
    att.Name = recName +'.pdf';
    att.ContentType = 'application/pdf';
    att.ParentId = recId;
    insert att;
}

I keep getting same Apex CPU timeout exceeded exception at around 14 second.

May be I'm understanding it incorrectly, but shouldn't I get 60 second timeout in @future method for executing PDF content?

Or my approach is flawed in some way?

== EDIT ==

What does this CRUC update do? - “PageReference getContent() and getContentAsPDF() Methods Behave as Callouts” Critical Update Postponed - Release Notes says that auto-activate date is postponed and not the update. Am I correct in reading that?

Answer 1

getContentAsPDF actually internally performs a callout back into Salesforce as a new transaction. This means that the actual CPU time used for the primary transaction doesn't account for the time used generating the PDF, and it gets its own governor limits.

Proof:

Class

public class vfWait5 {
    public vfWait5() {
        Long start = DateTime.now().getTime();
        while(DateTime.now().getTime()-start<5000);
    }
}

Page

<apex:page controller="vfWait5">
</apex:page>

Execute Anonymous

Page.vfWait5.getContentAsPDF();

Cumulative Usage for Execute Anonymous

  Number of SOQL queries: 0 out of 100
  Number of query rows: 0 out of 50000
  Number of SOSL queries: 0 out of 20
  Number of DML statements: 0 out of 150
  Number of DML rows: 0 out of 10000
  Maximum CPU time: 2 out of 10000
  Maximum heap size: 0 out of 6000000
  Number of callouts: 0 out of 100
  Number of Email Invocations: 0 out of 10
  Number of future calls: 0 out of 50
  Number of queueable jobs added to the queue: 0 out of 50
  Number of Mobile Apex push calls: 0 out of 10

Cumulative Usage for vfWait5

  Number of SOQL queries: 0 out of 100
  Number of query rows: 0 out of 50000
  Number of SOSL queries: 0 out of 20
  Number of DML statements: 0 out of 150
  Number of DML rows: 0 out of 10000
  Maximum CPU time: 4329 out of 10000
  Maximum heap size: 0 out of 6000000
  Number of callouts: 0 out of 100
  Number of Email Invocations: 0 out of 10
  Number of future calls: 0 out of 50
  Number of queueable jobs added to the queue: 0 out of 50
  Number of Mobile Apex push calls: 0 out of 10

Notice how I only generate 2 ms of execution time for a 5 second page render. The actual PDF page generates a separate log, where you'll see the ~5000 ms CPU time used. Also, you'll notice it has a normal 10000 ms limit (actual limit is, of course, flexible, but will probably never exceed 25000 ms).

So, in summary, you can never render a PDF that requires more than 10 seconds to render, even in asynchronous code. You can, however, render a pretty much unlimited number of PDFs that would far exceed the normal 60000 ms limit of asynchronous processes using this technique.

If you really wanted to do this, I'd suggest rendering the HTML in asynchronous code, save it to a Document/Attachment, then chain to a new asynchronous block and gather that data using a page that just echos the contents of a file into the page. You'll want to use Queueable or Batchable so you can get two chained transactions in order for this to work.

Answer 2

Please visit the below link:

https://releasenotes.docs.salesforce.com/en-us/summer16/release-notes/rn_cruc.htm?edition=&impact=

This update has been postponed until Winter'17