3 ms·
Crashing is a problem with wrappers for wkhtmltopdf library when they run concurrently (you need the right locks, some wrappers have this but not dink apparentl
by yyyk 4y ago
Crashing is a problem with wrappers for wkhtmltopdf library when they run concurrently (you need the right locks, some wrappers have this but not dink apparently?). However, process-based wkhtmltopdf wrappers are also available and don't have this problem at all (e.g. nreco. It's also not too difficult to create a wrapper for oneself).
- majkinetor 4y agoWe had very funky case - the crash happened couple of times per month only, with web app doing daily work via REST API producing very large collection of pdfs on single API request, each having from couple to 5k pages. It was very hard to troublehsoot and pinpoint memory corruption problem (took us several months, one doesn't expect this in C# app). Finally we switched to QuestPDF. Surprisingly, performance was exactly the same as with dink (which is surprising); I see in recent changelog 50% speed up on textual PDFs so this might be a game changer (TBH performance is great even now). BTW, we used dink for half decade in public web apps with millions of users. Dink was used to create PDF reports and we never had a crash in that concurent scenario. However, when we started doing typical non-web multithreading this started to happen.