Request to API & response

I'm Creating a bunch of pdf by paid account and some time it shows message "Sorry, we couldn't process your request" why this is happened? what is the reason for that?

Thanks
Jaff

Jaff,

Typically, we return this error when we forcibly cancel a long running request. From the client's standpoint, it is equivalent to the "Timed Out" message discussed here

Infrequently, the service might return this error when it fails to create a PDF due some internal problem.

We will definitely look into your problem if you give us more information about the failing requests.

I'm investigating above issue it is quit near to solve....it is some internal problem as you said.

I have another query:

Generating pdf in a loop some time it shows "Exceeded the limit on the frequency of API calls." and sometime this message is not happen.

What is the reason behind this...?
How many simultaneous call allowed?

Thanks,
Jaff

Jaff,

we return this error when the client sends more than 30 requests per minute from a single IP. This includes both the conversion requests and token queries. Please, see the updated API documentation at http://pdfcrowd.com/api/#api-ref-limitations.

As for the Sorry, we couldn't process your request message. Here are more details on when we return this error:

• The converted page loads more than 500 sub-resources (images, external stylesheets, js files, ..).
  
• There is more than 8 HTTP redirects when attempting to load a page sub-resource.
  
• The converted page refers to a truncated (i.e. corrupted) JPEG image - we have deployed a fix for that last weekend.
  
• It takes more than 40 seconds to process the request.
  
• Some internal problem.
  

Do you see this error often? If you are able to reproduce it and could provide us with the input html then we will look into it.

Thanks, we keeps sort out the things.

The message "we couldn't process your request message" is solved we are updated over html to less css and structure of html is alos modified to make sure all the tags are closed properly.

Some Background:

We are generating dynamic HTML for users that generated 50-200 htmls depending on the user selection of data, that HTML includes Js/single external stylesheet, images in each generated html. After that we read our dir/folder from server and calling all HTML in loop and using convertURI() pdfcrowd API call (php) for generating PDF.

This definitely exceed the limit [i.e 30call per min ] of the PDF for a single API

Progress:

When generating HTML ---to--- PDF some time it is generated 100+ psd and some time it limit upto 25 to 30, i think this is depend on the HTML response to generate psd

if our HTML page is less in size and few images then it generate more pages in a min - true?
By the way we have some few HTMS that uses lot of images when converting them limit exceed after 25 to 30 calls.

Is there any way to generate all pdf in a single call?
or is there any way to generate all pdf withsome delays?
What you suggest in that case?

Thanks
Jaff,

Jaff,

here are some tips:

• Do not call numTokens() after every convertURI() since it counts against the limit and thus you can create at most 15 PDFs per minute. If you want to track the number of remaining tokens then do it less frequently, for instance when you finish a batch of PDFs. By the way, we will send you an email notification when the number of tokens in your account drops below 1,000.
  
  
• It is perfectly ok to call convertURI() in a loop. If you catch an exception (PdfcrowdException $exc) then check $exc->getCode() and if it is 503 it most likely means that you are being rate limited. In such case just wait/sleep for one minute or so, repeat the last call that failed, and then continue your loop.
  
  

As for your multiple PDFs in a single call questions - it is not possible at the moment. However, it is likely that we will add such functionality in the future.

You could pre-calculate the number of tokens a conversion will use before you convert them; I do this for a bulletin system I recently made for someone. This gave them the option of seeing how many tokens it would use and whether or not they wished to continue. So far my esitmated tokens used has not been wrong.

Regarding the pages being to long, you could use jquery to calculate the height of the page and break it up into chunks of 'x' length. Then it is a matter of hiding and showing those chunks that are to be converted. I.E. 'http://www.mydomain.com/page.asp?chunk=3' too show only chunk 3 when converting to PDF!

Hope this helps a little,
It works a charm for me!

Regards,

Shane Simpkins

Thanks for Support & Search Path its help alot,

I do this by $exc->getCode() its works fine, whenever its return 503 its sleep 60secs every time. It coverts all pages 150 to 200.

Still one concern about the time due to sleep it takes 5 to 10mins to build approx 180 pages (in loop)

if multiple users access code / call for generating pdf in that case user receives 503 code until the first user call is completed by that multiple user have to wait alot?

Thanks - Ali

Jaff,

You can use a simplified bucket algorithm to create PDFs at the fastest possible rate without getting a 503 error. This should give you a better throughput than the previous suggestion.

$bucket = 30;
$last = microtime(TRUE);
for (..; ..; ..)
{
    if ($bucket == 0) sleep(2);
    $now = microtime(TRUE);
    if ($last + 2 <= $now) {
        $tokens = (int)(($now - $last) / 2);
        $bucket = min(30, $bucket + $tokens);
        $last += 2 * $tokens;
    }

    try {
        $client->convertURI(...);
        $bucket--;
    }
    catch(PdfcrowdException $why) {
        // log($why->getMessage());
    }
}

However, both solutions require that there is only one active loop at a time. Ideally, there should by a single loop in your application which processes requests from all users.

It seems that the API limits are too restrictive for your application. If you are interested, we can provision a private server dedicated to your application and optimized for your needs with the limits lifted. Please contact us at info@pdfcrowd.com if you would like to discuss this option.