Access Denied

Skip Navigation LinksHome  /  Support  /  Forums  /  DynamicPDF CoreSuite for .NET (v5)  /  Access Denied

DynamicPDF CoreSuite for .NET (v5) Forum

 Jun 27 2008 3:19 PM
I am creating about 100 PDF's and after about 16 are generated I get the following error:

System.IO.IOException: The process cannot access the file 'FileName.pdf' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at ceTe.DynamicPDF.Document.Draw(String filePath)

I have tried recreate the issue with the HelloWorld Console PDF on the server and modified it to generate 100 PDFs and it worked fine.

Any idea what I can do to eleminate this?
 Jun 27 2008 4:05 PM
Posted by a ceTe Software moderator
Is there something that has a lock on that file?  If you manually go into the file system are you able to modify that file?  Are you trying to access the file multiple times in this application?  Is the "FileName.pdf" the name of your output PDF or your input PDF?  Maybe you should post your code here (or if it is long you can just send it over to support@cete.com) and we can see if there is something obviously wrong with it.

Thanks,
ceTe Software Support Team
 Jun 27 2008 4:12 PM
The applications queries a large amount of data, creates the PDF, emails the PDF then moves on to the next user.  For one user this takes in the neighborhood of 10 seconds per user.  I have placed a few sleep statements in the code to slow the processing down and that seems to help a bit, but does cause another issue to.  The following error occurs several times through out the execution of the code now.

ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x201d68 to COM context 0x201ed8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

It really is starting to look like I am going to have to re-write the pdf creation piece.  This is a legacy application that I inherited.

All times are US Eastern Standard time. The time now is 2:42 AM.