File open error - Reason: PDF can not be opened

[tkittel]

Hello!



While testing a new flow (part of many flows), I'm running in an error when starting many files at the same time: File open error - Reason: PDF can not be opened;



To simplify, there is the following order:

1) input folder

2) XML pickup

3) TEMP1 folder (automanaged)

4) pdfToolbox profile

5) outgoing folder 1 for OK and warnings + outgoing folder 2 for errors



Starting many files at the same time, the pdfToolbox profile for some of them couldn't start because of the file open error is shown directly after TEMP1 folder. So some files will be routed to the outgoing folder 2 (error), instead of outgoing folder 1 (OK + warnings).



It seems that powerswitch will give the file to the following pdfToolbox profile, although it's not completed yet. So I tried to add an "hold job" for about 30 seconds like this:

1) input folder

2) XML pickup

3) TEMP1 folder (automanaged)

4) Hold job (30 seconds)

5) TEMP2 folder (automanaged)

6) pdfToolbox profile

7) outgoing folder 1 for OK and warnings + outgoing folder 2 for errors



But the error still exists. The only difference is, that the location of the error now is after "TEMP2 folder".



Is there another way to avoid the 'file open' error ?



Thanks in advance!

Thomas

[rzacherl]

Hello Mr. Kittel,



these kind of errors are well known and mostly result from massive parallel processing within a single instance of the pdfToolbox Profiles configurator within a Switch flow.

What are your Switch preference settings about the number of slots for concurrent execution? And what is the setting about the maximum number of external processes?



Introducing simply a global delay with help of Hold job is of course not a remedy for this problem because all you gain is that a bunch of jobs is hold back and released at the same time. So you simply delay the problem. What could be an effective means is to introduce an idle time between two successive jobs by using the appropriate Hold job setting. Also limiting the number of execution slots could help.



Regards,



Robert



BTW: putting a high number of jobs into a Switch flow at the same time was never one of the strengths of Switch.

[tkittel]

Hello Mr. Zacherl,



my general settings were: "number of slots" = 0 / "maximum number of external processes" = 10



To test at a very high level, I tried to copy 20 pdf files and 20 XML files at the same time, which results in 15 "open file" errors. Adding an "hold job" reduces the number of errors a little bit.



So I tested (with added "hold job") some combinations of number of slots / max no. of ext. processes:

1/10 -> 15 errors

8/3 -> 8 errors

8/2 -> 5 errors

8/1 -> 0 errors (1st test)

8/1 -> 14 errors (2nd test)

8/1 -> 14 errors (3rd test)



While the first '8/1->0' test our server was slow, because of high traffic. While the last two tests server had it's normal performance. So I think, however I'll combinate the max. no. of ext. processes and the number of slots at the moment; there will be some more details which take effect to the resulting number of errors.



Because of the pressure of time I'll ignore this problem for today. In my tests 4 pdf files and 4 xml files starting in the flow at the same time seems to be the critical value. In practice it would be very rarely, that more files will reach this flow at the same time.



Thank you for your answer!

I'll renew this thread, if this will become a really problem in practice.



Have a nice day,

Thomas