Problem using Memorystream in TASK?

[DavidBS]

Hi everyone!

I have a routine that protect PDF's and sign them using Memorystream as the intermediary layer - I mean, the protected document is saved to a Memorystream and the sign process get it as the entry file. No problem at all.

Interesting notice that, if I put this routine in a concomitant task, I have the following problem during the final "SAVE" (the signing process) to a disk file, but SOMETIMES only:

 at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)

   at System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()

   at Syncfusion.Pdf.Primitives.PdfDictionary.SaveItems(IPdfWriter writer)

   at Syncfusion.Pdf.Primitives.PdfDictionary.Save(IPdfWriter writer, Boolean bRaiseEvent)

   at Syncfusion.Pdf.Primitives.PdfStream.Save(IPdfWriter writer)

   at Syncfusion.Pdf.IO.PdfCrossTable.DoSaveObject(IPdfPrimitive obj, PdfReference reference, PdfWriter writer)

   at Syncfusion.Pdf.IO.PdfCrossTable.SaveIndirectObject(IPdfPrimitive obj, PdfWriter writer)

   at Syncfusion.Pdf.IO.PdfCrossTable.SavePrimitive(IPdfPrimitive obj, PdfWriter writer)

   at Syncfusion.Pdf.IO.PdfCrossTable.SaveObjects(PdfWriter writer)

   at Syncfusion.Pdf.IO.PdfCrossTable.Save(PdfWriter writer)

   at Syncfusion.Pdf.Parsing.PdfLoadedDocument.AppendDocument(PdfWriter writer)

   at Syncfusion.Pdf.Parsing.PdfLoadedDocument.Save(Stream stream)

   at Syncfusion.Pdf.PdfDocumentBase.Save(String filename)

Why in a task?

Because sometimes the entry document is really a bunch of 20 documents (the general situation here), related to the process. And I'm trying to accelerate the process protecting-and-signing processing 2 files at once.

As I said, 95% of time (or files) the routine functions 100% but sometimes 1 or 2 files raises the above error - and it does not occur if I just sign the document, which does NOT involve the usage of "Memorystream". In those cases, the routine process disk files directly (input and output).

Interesting notice that the Memorystream is not shared or public (it is created within the method).

Does anyone would know why I have a problem here?

Thanks!

[DavidBS]

Hmmm....

Even bypassing the error using a deviation based on TRY-CATCH (and calling again the SAVE method), in some files I get:

   at System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count)

   at Syncfusion.Pdf.Primitives.PdfStream.Write(Byte[] data)

   at Syncfusion.Pdf.IO.PdfStreamWriter.SetTextRenderingMode(TextRenderingMode renderingMode)

   at Syncfusion.Pdf.Graphics.PdfGraphics.ApplyStringSettings(PdfFont font, PdfPen pen, PdfBrush brush, PdfStringFormat format, RectangleF bounds)

   at Syncfusion.Pdf.Graphics.PdfGraphics.DrawStringLayoutResult(PdfStringLayoutResult result, PdfFont font, PdfPen pen, PdfBrush brush, RectangleF layoutRectangle, PdfStringFormat format)

   at Syncfusion.Pdf.Graphics.PdfGraphics.DrawString(String s, PdfFont font, PdfPen pen, PdfBrush brush, RectangleF layoutRectangle, PdfStringFormat format)

   at Syncfusion.Pdf.Graphics.PdfGraphics.DrawString(String s, PdfFont font, PdfPen pen, PdfBrush brush, Single x, Single y)

And the testes are NOT using Memorystream: I'm just opening the documents at the disk, signing them and writing again into disk.

The problem may be related to multithreaded processing...

[DavidBS]

Hmmm....

Even creating a CLASS with all signing procedures there and loading it twice (each one for each thread/task) I have the same behaviour: the SAVE procedure raises an error ("the collection was modified, maybe the enumeration operation won't be executed").

Interesting that bypass:

Try

loadedDocument.Save(DestFile)

loadedDocument.Close(True)

Catch ex As Exception

Try

Threading.Thread.Sleep(10)

loadedDocument.Save(DestFile)

loadedDocument.Close(True)

Catch ex2 As Exception

End Try

End Try

... when the file is saved normally although the error.

[Sowmiya Loganathan]

Hi DavidBS,   

  

Thank you for contacting Syncfusion support. Please find the details from below,   

  

I have a routine that protect PDF's and sign them using Memorystream as the intermediary layer - I mean, the protected document is saved to a Memorystream and the sign process get it as the entry file. No problem at all.      Interesting notice that, if I put this routine in a concomitant task, I have the following problem during the final "SAVE" (the signing process) to a disk file, but SOMETIMES only:      Because sometimes the entry document is really a bunch of 20 documents (the general situation here), related to the process. And I'm trying to accelerate the process protecting-and-signing processing 2 files at once. As I said, 95% of time (or files) the routine functions 100% but sometimes 1 or 2 files raises the above error - and it does not occur if I just sign the document, which does NOT involve the usage of "Memorystream". In those cases, the routine process disk files directly (input and output).      Interesting notice that the Memorystream is not shared or public (it is created within the method).

We have tried to reproduce the reported issue with 20 PDF documents in multi-threading with protecting and signing PDF documents. But we regret to let you know that we were unable to reproduce it. Please find the sample from which we tried from below,       Sample:https://www.syncfusion.com/downloads/support/forum/162532/ze/PdfSample88491988      Could you please provide us the below details, it will helpful for us to provide the precise solution on this.       Modified sample Product version

Even bypassing the error using a deviation based on TRY-CATCH (and calling again the SAVE method), in some files I get:      Even creating a CLASS with all signing procedures there and loading it twice (each one for each thread/task) I have the same behaviour: the SAVE procedure raises an error ("the collection was modified, maybe the enumeration operation won't be executed").

Could you please provide us the below details, it will helpful for us to provide the precise solution on this.       Code snippet or sample Input PDF documents

  

Regards,  

Sowmiya Loganathan