Cannot start Task

operations

(Anthony) #1

Hi,

I have a deployment to multiple tenants on the same server that use the Redgate Deploy from Package Step Template.
During deployment I get the following wait statement:

  • "Cannot start this task yet because “ServerTasks-nnnn” (has a write lock) tasks are currently running and this task cannot be run in conjunction with any other tasks. "

I can’t find what the process tasks are waiting on to see if i need to add different directories per tenant.

Have you any ideas as to what is causing the write lock?

Cheers,

Anthony


(Daniel Fischer) #3

Hi Anthony,

thanks for getting in touch! I’ll need to get some further information to help troubleshoot this issue. Would you be able to attach the full raw deployment log where you are seeing this message?

And to possibly save some back and forward, In the message you see, does the ServerTasks-nnnn have a value where I see nnnn?

If so, can you brows to the api page for this task and see if it has any further information?

http://YourOctopusServer/api/tasks/ServerTasks-1234

Let me know how you go here. :slight_smile:

Looking forward to hearing from you,

Best regards,


(Anthony) #4

Hi Daniel

Raw Log below:
ServerTasks-5185.log.txt (62.6 KB)

The text from the Server Task is as below, the locking task is not always the same one, (all of the tasks are doing the same process):
{
“Id”: “ServerTasks-5182”,
“Name”: “Deploy”,
“Description”: “Deploy 2. Data Warehouse Customer Level Deployment release 0.0.51 to DEV for [ARB][ARB][ARB87C3A7BA543CF8A6572BB0F7A43C0]”,
“Arguments”: {
“DeploymentId”: “Deployments-1113”
},
“State”: “Success”,
“Completed”: “17 August 2018 09:51:42”,
“QueueTime”: “2018-08-17T08:50:55.335+00:00”,
“QueueTimeExpiry”: null,
“StartTime”: “2018-08-17T08:50:55.476+00:00”,
“LastUpdatedTime”: “2018-08-17T08:51:42.240+00:00”,
“CompletedTime”: “2018-08-17T08:51:42.240+00:00”,
“ServerNode”: “OctopusServerNodes-DEVDWOCT01”,
“Duration”: “47 seconds”,
“ErrorMessage”: “”,
“HasBeenPickedUpByProcessor”: true,
“IsCompleted”: true,
“FinishedSuccessfully”: true,
“HasPendingInterruptions”: false,
“CanRerun”: false,
“HasWarningsOrErrors”: false,
“Links”: {
“Self”: “/api/tasks/ServerTasks-5182”,
“Web”: “/app#/tasks/ServerTasks-5182”,
“Raw”: “/api/tasks/ServerTasks-5182/raw”,
“Rerun”: “/api/tasks/rerun/ServerTasks-5182”,
“Cancel”: “/api/tasks/ServerTasks-5182/cancel”,
“State”: “/api/tasks/ServerTasks-5182/state”,
“QueuedBehind”: “/api/tasks/ServerTasks-5182/queued-behind{?skip,take}”,
“Details”: “/api/tasks/ServerTasks-5182/details{?verbose,tail}”,
“Artifacts”: “/api/artifacts?regarding=ServerTasks-5182”,
“Interruptions”: “/api/interruptions?regarding=ServerTasks-5182”
}
}

regards,

Anthony


(Daniel Fischer) #5

Hi Anthony,

Thanks for getting back with this information. However, I can not see anything too out of the ordinary here.

From what you have told me, you have multiple Tenants on the same server. Octopus creates a separate task for each Tenant you deploy to and since these tasks are running on the same target server, Octopus needs to queue some parts of the deployment whilst others occur.

This is by design and intended to stop Octopus tripping over itself and breaking/corrupting files.

It looks like your deployments did not have any errors and completed fairly quickly. Aside from the message you are seeing, are there any problems with the deployment?

Looking forward to hearing from you. :slight_smile:

Best regards,
Daniel


(Anthony) #6

Hi Daniel,

The change for the log you saw was a single update to a view, to get the process to run, for 7 tenants, so the run time was not so long. If I do a larger change the duration extends.

We don’t get any failures, it’s just the run duration that is a pain. In our dev environment if I have 10 plus tenants on a single tentacle the tenants can sit here until they get a slot, which means it takes more than 10 minutes to deploy them all, as they seem to have to take it in turns to process, due to the wait for write lock. When we go to live we may have 100 tenants and I’m trying to circumvent an issue.

Is there any way you can let me know what is causing the lock, as I can’t see any details from the logs other than it is another task. Each process runs against a different database and each follows the same steps and should be able to be separated, is there anything I can change in my set up that fully separate the tenant processes. Can we find out why there is a lock?

regards,

Anthony