IronPDF deadlocks when running in parallel

Question

I'm trying to generate multiple PDFs in parallel using IronPDFs HTML to PDF feature. But it appears to be deadlocking when started from ASP.NET :(

I've recreated the problem here: https://github.com/snebjorn/ironpdf-threading-issue-aspnet

Here's a snippet with the essential parts.

Calling GetSequential() works. But is not executing in parallel. GetSimple() is running in parallel but deadlocks.

public class TestController : Controller
{
    [HttpGet]
    [Route("simple")]
    public async Task<IActionResult> GetSimple()
    {
        var tasks = Enumerable
            .Range(1, 10)
            .Select(i => HtmlToDocumentAsync("hello", i));
        var pdfs = await Task.WhenAll(tasks);

        using var pdf = PdfDocument.Merge(pdfs);
        pdf.SaveAs("output.pdf");
        return Ok();
    }

    [HttpGet]
    [Route("seq")]
    public async Task<IActionResult> GetSequential()
    {
        var pdfs = new List<PdfDocument>();
        foreach (var i in Enumerable.Range(1, 10))
        {
            pdfs.Add(await HtmlToDocumentAsync("hello", i));
        }

        using var pdf = PdfDocument.Merge(pdfs);
        pdf.SaveAs("output.pdf");
        return Ok();
    }

    private async Task<PdfDocument> HtmlToDocumentAsync(string html, int i)
    {
        using var renderer = new HtmlToPdf();
        var pdf = await renderer.RenderHtmlAsPdfAsync(html);

        return pdf;
    }
}

According to https://medium.com/rubrikkgroup/understanding-async-avoiding-deadlocks-e41f8f2c6f5d it's because the thread executing the controller method isn't a main thread. So it just gets added to the thread pool and at some point we're waiting for the controller thread to continue but it's not getting scheduled back in. This happens when we mix async/await with .Wait/.Result.

So am I right to assume that there are .Wait/.Result calls happening inside the IronPDF.Threading package?

Is there a workaround?

---

UPDATE:

I updated to IronPdf 2021.9.3737 and it now appears to work

Also updated https://github.com/snebjorn/ironpdf-threading-issue-aspnet

Answer 1

Just wanted to add to this that IronPdf's multi-threading support on MVC web apps is non-existent. You will end up with indefinite deadlocks if you're rendering in the context of an HTTP request. We have been strung along with the promise of an updated renderer that would resolve the issue (which we were told should be released June/July 2021) but that appears to have been pushed back. I tested the updated renderer using their 'early-access package' and the deadlocking has been replaced by 10 second thread blocks and seemingly random C++ exceptions, so it's far from being fixed. Performance is better single-threaded.

Darren's reply is incorrect - I've stepped through our render calls countless times trying to fix this, and the deadlock comes on the HtmlToPdf.StaticRenderHtmlAsPdf call, not on a PdfDocument.Merge call. It's a threading issue.

I suggest avoiding IronPdf if you haven't already bought their product. Find another solution.

Answer 2

I used IronPDF on the 2021.9.3737 branch without any threading issues on windows and Linux today thanks to Darren's help in another thread.

• Documentation: https://ironpdf.com/object-reference/api/
• Nuget: https://www.nuget.org/packages/IronPdf/
• Source of information: C# PDF Generation (using IronPDF on Azure)

I agree with abagonhishead that StaticRenderHtmlAsPdf used to create a que of PDF documents to be rendered, and on an under-provisioned server it ended in a thread deadlock... the que getting longer and longer as the server struggled to render PDFs.

Solution that worked for me:

• moving to a well provisioned server (Azure B1 for example)
• (and/or) moving to IronPDF latest Nuget 2021.9.3737

Answer 3

Support for Iron Software here.

Our engineers tested your sample project, increasing to 150 iterations and saw it running without issue.

Our expectation of your use-case is that you are creating multiple threads to generate PDF files and store these files into an array for merging later?

Assuming this is the case, the likely cause of this issue is sending too large an array to the merge method, which requires a large amount of RAM to process. The crash is the memory not handling the large number of PDFS to merge.

Answer 4

as you can see from the attached image, I tested your code with 1000 iterations and it works without issues, I believe the problem may occur when you increase the iterations or input big HTML size that reaches the max CPU and memory capacity that can't handle. also, I don't agree with abagonhishead because there is not an alternative solution in the market that offer all these features