We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Multithreading issue PNGDevice

Hi,

we are using Aspose PDF library to convert PDF pages of multiple documents to PNG images within multiple threads (up to 10) using following code:

// Load the input PDF document
using (Aspose.Pdf.Document pdfDocument = new Aspose.Pdf.Document(filePath))
{

// Render the page into a raster image
using (MemoryStream imageStream = new MemoryStream())
{
// Create Resolution object
Resolution res = new Resolution(resolution);
if (format == ImageSaveFormat.PNG)
{
// Create PNG device with specified attributes
PngDevice pngDevice = new PngDevice(res);
// Convert a particular page and save the image to stream
pngDevice.Process(pdfDocument.Pages[pageNo], imageStream);
...

After processing of some large amount of PDF files (about 1 Gb) process is stuck within pngDevice.Process method at 100% CPU load and remains in this state forever (see attached image of stacktrace analyser) .

Please advice on correct usage of library in multithreaded environment. Please also take a look at following link
http://improve.dk/debugging-in-production-part-1-analyzing-100-cpu-usage-using-windbg/
it seems that static Dictionaries used here are not thread safe - unfortunately we cannot analyse problem further on our end.

Thanks & Best Regards
Hi Shai,

Thanks for your inquiry. Are you converting some specific page numbers of PDF document to PNG or all pages? We will appreciate it if you please share your working sample code, so we will test the scenario and provide you information accordingly.

Moreover, please note processing time depends upon the file size/contents and system resources. Aspose.Pdf does not use temporary files for processing but memory. So performance can be suffered due to large file processing.

Furthermore, in reference to multithreading support, please note Aspose.Pdf is multithread safe as long as only one thread works on a document at a time. It is a typical scenario to have one thread working on one document, different threads can safely work on different documents at the same time.

We are sorry for the inconvenience caused.

Best Regards,

Hi Ahmad,


thank you for quick response.

Every PDF document has only one page so only one page is extracted.
Only one thread has access to the document.
There should not be a problem to prepare sample, just continuously run the code I provided in 10 worker threads.

File size of one page PDF document always remains low so it is not a performance issue.

Please investigate the source code of PNGDevice and usage of static members of Dictionary - they are not thread-safe and could have causing the deadlock.



Hi Shai,


Thanks for you feedback. I have tested scenario with a sample PDF document using following code and noticed that CPU usage rises to 100%, it hangs for some time but returns to normal after some time. So I have logged a ticket PDFNEWNET-39309 for further investigation and rectification. We will notify you as soon as it is resolved.

try<o:p></o:p>

{

for (int i = 0; i <10;i++ )

{

Thread t = new Thread(convertpdftopng);

t.Start();

}

Console.WriteLine("conversion is done...");

}

catch (Exception error)

{

Console.WriteLine(error.ToString());

}

public static void convertpdftopng()

{

try

{

using (Aspose.Pdf.Document pdfDocument = new Aspose.Pdf.Document("E:/data/A1-28 - PRECAST STADIA - UPPER BOWL.pdf"))

{

// Render the page into a raster image

using (MemoryStream imageStream = new MemoryStream())

{

// Create Resolution object

Resolution res = new Resolution(300);

// Create PNG device with specified attributes

PngDevice pngDevice = new PngDevice(res);

// Convert a particular page and save the image to stream

pngDevice.Process(pdfDocument.Pages[1], imageStream);

}

}

}

catch (Exception ex)

{

Console.WriteLine(ex.StackTrace);

}

}

We are sorry for the inconvenience caused.


Best Regards,

Hi,
with version 21.10.0 we still have hang-ups with PngDevice.Process(). It seems that the same problem underlies the PDFNEWNET-39309. As Docit has already described, the problem lies with the access to System.Collections.Generic.Dictionary’, which was not implemented thread save. Tracking down the error seems to be a bigger problem. However, the documents do not play a role here. It is only important that several threads have read and write access nearly at the same time to the same dictionary. Can’t rule out that methods other than ‘Process’ are not needed for this error to occur. Please check all static lists of the type ‘System.Collections.Generic…’ and make them thread save.

Stacktrace:
C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Collections.Generic.Dictionary`2.FindEntry+0xaa
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zjy61W7nMqkr7P3pON0KiUlTScck6ue0deA==.#=zQ9HgtlpZrgyX+0xf7
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=ziCn8xkhpEvz81VUi9_dYA2ipqzKqqmmpgYmxlLTWdR$N.#=zEWQaAv4=+0x8b
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zigVcVy0kF4TRalKjQfSZwe$6RQBq15y9G$BisMX6iz0$.#=z9cZxLEiSM$m4+0x63
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zigVcVy0kF4TRalKjQfSZwe$6RQBq15y9G$BisMX6iz0$.#=zhmMyXlamo1Di+0x68b
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zigVcVy0kF4TRalKjQfSZwe$6RQBq15y9G$BisMX6iz0$.#=zhmMyXlamo1Di+0x15
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zigVcVy0kF4TRalKjQfSZwe$6RQBq15y9G$BisMX6iz0$.#=zieixP4E=+0x21
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zvTBSW6Zaed0wowLrUj9HKmHxXquTNkCN48aB5Spy3ZHfPWx1Nw==.#=zERAke7l_Mq5V+0x89e
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=ziCn8xkhpEvz81VUi9_dYA2ipqzKqqmmpgYmxlLTWdR$N.#=zTF_Ihb4gxzYv+0x25
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=ziCn8xkhpEvz81VUi9_dYA2ipqzKqqmmpgYmxlLTWdR$N.#=zzbIY2mc=+0x24
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zigVcVy0kF4TRalKjQfSZwe$6RQBq15y9G$BisMX6iz0$.#=zurYkq3cZfvny+0x208
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=zigVcVy0kF4TRalKjQfSZwe$6RQBq15y9G$BisMX6iz0$.#=zieixP4E=+0x20a
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=z4fCDDtM8J1XRJuuQUjMZljojLfnB.#=zV1190C8=+0x914
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!#=z4fCDDtM8J1XRJuuQUjMZljojLfnB.#=zV1190C8=+0x15
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!Aspose.Pdf.Devices.ImageDevice.#=zV1190C8=+0x9a
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\bau\b5043016\58100ddd\assembly\dl3\141cbbdd\002b5099_7f60d701\Aspose.PDF.dll!Aspose.Pdf.Devices.PngDevice.Process+0x18
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET

Thanks & best regards

@daniel.wolf

Can you please try using 21.12 version of the API and if issue still persists, please share your sample PDF document along with the code snippet and environment detailed information so that we can try to replicate the issue in our environment and address it accordingly.

As already described, the document does not matter. It’s only about the non thread save access to the dictionary. The FindEntry in System.Collections.Generic.Dictionary will never return. See also https://stackoverflow.com/questions/33153485/is-it-possible-for-a-dictionary-in-net-to-cause-dead-lock-when-reading-and-writ/33153868. It is very difficult to reproduce this because it depends on several threads accessing a static dictionary at the same time.

@daniel.wolf

We have opened another investigation as PDFNET-51200 in our issue tracking system to analyze this scenario with the latest version of the API. We will further look into its details and keep you posted with the status of its rectification. Please be patient and spare us some time.

We are sorry for the inconvenience.