0

Just switched from .Net 1.1 to 3.5 on Win service active for 10 years with over 2 million files processed. I have an asynchronous class that prints graphics to a PDFPrinter with a FileSystemWatcher event handler, now on its own STA thread, archiving the PDF files. The PDF creation is asynchronous because of an existing client application method permitting creation of all missing PDFs in a DateTime interval.

(1) Without the event handler spun off on an STA thread, the service hangs.

(2) With only a few PDFs arriving within a few-second interval, it works fine. Increase that to 5 PDFs and inevitably one file doesn't get archived. Increase that to 15 PDFs and several don't get archived (all this in a test bed). Before moving a file, I check that it exists, requiring 2 successful detections (PDFPrinters tend to produce phantom file-creation events). I also check for exclusive access to the file. Update: I tried another STA thread-creation approach (via a parameterized class and method) in a different section of COM-interacting code, and had the same problem with unreliability (only about 50% of threads complete).

For PDFs, I was tempted to setup a Timer to archive abandoned files, but am unclear when to start the Timer so as to avoid having multiple Timers trying to do the same archiving task (with additional danger of Oracle concurrency problems); that design feels a bit like belt and suspenders (negative ugh factor).

This is such a common paradigm, it shouldn't be this difficult to make robust! Looking for enlightenment on (1) and help with making new STA threads complete reliably (2).

PSEUDOCODE

Test bed user interface:
    // Process 20 instrument raw data files in a loop
    // For each file:
    // 1-2 s to setup processing and retrieve metadata from database on each file
    // (A) spin off STA worker thread
    // call instrument vendor COM API to read data file
    // setup FileSystemWatcher for PDF files
    // create graphical image PDF
    // handle PDF_Created in a shell that ...
    // (B) spins off STA worker thread to 
    // archive the PDF
beanmf
  • 493
  • 5
  • 7
  • 1
    Can you share the simplest reproduceble code sample so we have code to reason about? – rene Apr 20 '14 at 21:13
  • I truly wish; the best I might be able to do is pseudocode. Any comments on what I've written would be welcome though. – beanmf Apr 20 '14 at 21:36

1 Answers1

0

Answering (2): I had to add code to linearize or resynch the new STA thread with the old MTA thread (e.g. block the parent thread until the worker thread completes).

thread.Join();

That worked well at point (A) in the pseudocode, but not at point (B) where I had some shared field variables that still need to be moved into thread parameters (potential cause of not all PDFs being created)

I confess to still not understanding why a FileSystemWatcher that archives files across the network needs to be handled on a STA thread (question (1)).

beanmf
  • 493
  • 5
  • 7