I have a try-catch in which I enumerate files and use async action to run 4 threads, which in turn run same target in which I check file for digital signature and sign it if signature is missing.
Periodically, this logic is breaking but that is not the question here. The problem is that script does not catches the exception, it just stops its run.
This is build script setup
This is log file
As you see, script just exits and nothing handled. Thank you
please send your project file to support @ finalbuilder.com so we can try to reproduce it here. Ideally, if you can narrow it down to a small test project that would result in a faster resolution.
Also, what version/build of FinalBuilder are you using?
FB v8.0.0.2442. Thank you
@Vincent Thank you. I’ve sent the file over. I cut out the piece in question and tested it - it runs. More description is in email.
PS: Additionally, I experimented with “Raise Exception” and if I place it in one or 2 of the thread action groups, it would wait until other threads exited and then go into catch as expected.
I’ve had a play with your project, but unfortunately it does not reproduce the problem.
That said, this project has some design issues.
Using multiple threads in this way to process a fileset is not a good idea. I can see what you are trying to achieve, however a much simpler option is to use a queue.
We have an example project here
This project shows how to use multiple threads to process items in a queue. To add the fileset to the queue, you can use this expression
%_finalDigiSignFiledset.ALLFILES:sep=crlf%
This will add each file to the queue. I would recommend experimenting with the number of threads to get the best performance, as more threads does not automatically mean better performance.
In your processing target you should handle exceptions with a try catch, and set a variable to indicate that an error occurred. Otherwise the async group will just receive the exception and stop all threads.
Hmm… not sure if that is the intended behaviour but I just tested and see that. I suspect this changed somewhere along the way, as
Ok. I will rework it using a queue. Thank you. Yes, when real signing is going on, it works 3 times out of 4. Without signing, it worked every time. Just curious at this time - is it possible that simultaneous access to fileset count could cause this? Or it is somehow connected to a network disruption during signing. It is true that sometimes these digisign servers are to busy or something like that. Thank you for all the tips!
Ok, Sir. Implemented queue-based logic. It works. Will see if it breaks again in real time digital signing.
@Vincent There were at least 5 builds since I changed the action and so far not one fail due to same issue. Thanks