Normal0<w
Hi Nick,
Could you provide more information about the project and how it is run? I’ve tried to reproduce the problem here (1000 runs of start/stop) and it doesn’t error out. Is it being run under FinalBuilder Server, the command line, windows scheduler? Is it a built-in windows service your stopping? Does it have dependencies? If you could send in your project to support [at] finalbuillder.com that would be helpful.
Regards,
Paul.
It fails when running FinalBuilder Professional Edition Version 7.0.0.713. The widows service is hosting a WCF Service. After running multiple times the script fails randomly through out, the latest is just copying files from one server to the next. I have attached the project for your review. As you will see it is very dynamic in that we are driving the whole script from database tables. One thing to note it fails more readily doing one of our larger deploys 20 Application Servers and 14 Web Servers.
Standard_Deploy.fbp7 (1.095 MB)Hi Nick
Failing randomly is not good. After looking at you project my guess is it’s a resource protection issue… I will attempt to get the project to run here in some form and see what I can find.
My first though after looking at your project thought is that I hope you have a machine with quad 12 core cpu’s, because it looks at though it could be running a lot of threads at a time. You have some redundant ASync groups under ASync groups (with only 1 child action under the last async group) which just adds overhead (thread switching, more resource locking etc). In general you should aim to have as many threads running as you have cores, and preferably less than that. In our stress testing, we have found that some times doing things in serial is actually faster than in parallel.
I would prefer that we work to resolve this issue via email, please contact support @ finalbuilder.com and we’ll try and figure out what the cause of this problem is and how to fix it.
Hi Nick
I just realised you probably work with Nick C (or at least at the same company), if that is the case then he currently has an open support case with us for what sounds like the same problem. I sent him a test build a few days ago (build 721) which had some fixes however I think I may have found a possible cause.
I have just been trying some constructs that I see in your project file, and I see some random failures due to a misuse of the Queue/Stack Iterator action. This action will empty the queue, however it's not designed to be used in the way that you are using it.. with 4 instances of the same action list under an async group the actions. Iterators look at the list they are iterating on the first iteration and get the count of items, however with multiple iterators working on the same queue this will probably not be have as desired. The Iterate Queue action is somewhat ill conceived.. I will spend some time tomorrow and see if it's behavior can be changed to cope with async operation.
Hi Nick
Please try the latest official update, it includes a reworked Stack/Queue Iterator action which should be have better when multiple instances are run against the same queue.