I’m using the demo version of FinalBuilder (6.2.0.1265), and setting the retry counter in the runtime timing properties page does not work at all unless you also set a timeout value, and then it uses the timeout value between retries.
Bill
Hi Bill
Which action was this on? I just tried here with an execute program action and it worked fine… however some action override the default behaviour so it’s possible it’s only happening with a particular action.
It was on a Mutex/File Locking action I placed to control access to an INI file containing some counters that needed to be updated synchronously across all hypothetical build executions.
With the timeout set for 1 minute, and the retry timeout set for 999 milliseconds and a count of 5, you can see that two retries took 2 minutes.
I changed the action to use the create/delete of a separate lock file, and this shows the same problem if the lock file is opened in exclusive mode by another process ( I used Excel to open Process.lck).
Here’s the excerpt from the build log showing this:
- Action List Action List: Update Build Info 12:52:35 12:54:40 00:02:04
Completed Mutex/Lock File Action Lock File [ C:\Projects\Ceuless\SrcTree\Process.lck ] 12:52:35 12:54:40 00:02:04 View
Mutex action running…
Using file : C:\Projects\Ceuless\SrcTree\Process.lck
Action Timed out.
Retrying action (1 of 5)…
Mutex action running…
Using file : C:\Projects\Ceuless\SrcTree\Process.lck
Action Timed out.
Retrying action (2 of 5)…
Mutex action running…
Using file : C:\Projects\Ceuless\SrcTree\Process.lck
It also makes a difference if you have the timeout enabled or disabled: if the timeout is disabled it doesn’t even do the retries (at least not within the 5 minutes I let it sit there before cancelling the process).
Bill
Hi Bill
This is actually as designed… if you don’t specify a timeout then it will wait indefinitely. The only time the retry makes sense for that action is if you are waiting for the file to be created by another process. With hindsight it might have been better if we had defaulted to not waiting at all unless a timeout was specified, I am wary of making such a behavioral change now as that might break peoples builds if they rely on the existing behavior.
When I re-thought it through, that’s the ultimate conclusion I came to as well: that the retry mechanism wasn’t intended to be available for the Mutex/File lock operation. A possibly safe change to make would be to disable the retries selection for the mutex action, rather than alter the behaviour of the mutex lock ( or update the action description with the behaviour).
Could you let me know what (if any) queueing policy is used in the case of multiple processes/machines waiting for a shot at a file protected in this way? I’d assume that it’s FIFO order, but I’ve found that assumptions are generally wrong N times out of (N-1) possibilities when dealing with software. Bill
Hi Bill
Note sure if we can disable the retry stuff for the action, it’s done at a much lower level than the action implementation.
As for queuing, that’s difficult to answer. When acquiring a file, we loop on the window CreateFile until it succeeds … so it’s probably unwise to assume any sort of order if multiple processes are waiting on a file lock as I doubt there would be any predictable order. When acquiring a mutex, it’s up to windows who get’s first shot at it, I remember reading somewhere that you shouldn’t make any assumptions on that either.