Hi there,
Recently, I set up an Azure DevOps release pipeline that copies OL Connect resources to the C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\Documents\In folder.
Yesterday, an error occurred with the message: “The process cannot access the file ‘C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\Documents\In\xxxxxx.OL-template’ because it is being used by another process.”
Since I couldn’t understand why the pipeline failed, I redeployed it, and it finished correctly.
In my imagination, the Workflow Service is constantly monitoring the C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\Documents\In folder. Therefore, it’s possible that the Workflow Service’s monitoring process and the Azure DevOps release process might have coincidentally collided.
Does anyone think my imagination is correct?
If my understanding is correct, does anyone have a solution? I’d like to release OL Connect resources using the Azure DevOps release pipeline without having to manually stop the Workflow Service.
An Azure DevOps service does not have administrative privileges, so it cannot stop the Workflow Service. Does anyone know how I can avoid errors in the release pipeline?
Thank you
Your assessment of the situation is correct, this is how things work.
You did not specify whether the error message was on the side of Workflow or Azure. In theory, Workflow should wait until the file is finished being written before processing it, so in this context, this is a case of “this should not happen”. It is possible that, in the fraction of a second between the time at which Workflow validates that the file is ready to be processed and the time at which it actually starts processing it, Azure deploys another copy, in which case Workflow finds the file unaccessible.
On the other hand, if the error is on the side of Azure, perhaps the template was deployed twice in rapid succession, with the second deployment occurring while the first was still being processed.
Another likely cause would be interference by an anti-malware software, which lock the file while it is being scanned. Due to its nature, Workflow is often targeted by such software. Many unexplainable, “should not happen” problems have turned out to be caused by overly aggressive anti-malware over the years. It is recommended to exclude a number of paths, the details of which are explained in the documentation. See here for example: Antivirus considerations.
1 Like
Hi @fortiny ,
Thank you for your reply. For the Azure Release Pipeline, I would like to add the ‘net stop ppwatch8’ command before copying resources and the ‘net start ppwatch8’ command after copying resources. I am wondering if this plan will work well with the Workflow Service.
Thank you,
Kiyomi