You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 20, 2020. It is now read-only.
setup a new worker and set numberOfTasksToRun to 1.
start worker
create a task for the worker to pick
the worker runs the task, and exits as expected.
restart the worker
create another task
the worker runs the task, and stays running. It will stay up forever and pick new tasks.
Alternative scenario:
setup a new worker
start worker
create tasks to test the worker
kill worker
change numberOfTasksToRun to 1
restart worker
create tasks
worker stays up forever and picks new tasks as they come.
Essentially, the problem is that tasks-resolved-count.txt persists the number of tasks the worker has done between worker runs, and numberOfTasksToRun is compared against that persisted number, not the number of tasks that have been run since the worker process started for the last time.
The text was updated successfully, but these errors were encountered:
One of the challenges we have here is that e.g. on Windows, we need to reboot between tasks, since we want a winlogon session to be created for the new task user, which we can only achieve by rebooting. In this case, if you want to run e.g. 4 tasks only, we need to persist the number of tasks we have run so that the worker runs a task, reboots, runs a task, reboots, runs a task, reboots, runs a task, stops.
I agree that if we start the worker, and the number of tasks to run equals the number of tasks run (tasks-resolved-count.txt) that the worker should just exit - it sounds like it is running tasks indefinitely in this case.
On platforms that don't need to reboot between tasks, I see that the setting numberOfTasksToRun would be more intuitive if it ran that number of tasks before exiting the process.
I'm happy for us to change the implementation, at the moment I'm not sure what a good design would be that suits both windows and non-windows platforms. Perhaps I should disable the feature on Windows, since it exits after each task anyway, and if the user wishes to control how many tasks they run, they can do that by counting how many times they launch the worker... 🤔
Suggestions welcome for an approach that makes sense on all platforms, and I'll have a think about this too.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
numberOfTasksToRun
to 1.Alternative scenario:
numberOfTasksToRun
to 1Essentially, the problem is that
tasks-resolved-count.txt
persists the number of tasks the worker has done between worker runs, andnumberOfTasksToRun
is compared against that persisted number, not the number of tasks that have been run since the worker process started for the last time.The text was updated successfully, but these errors were encountered: