There is a problem where if the multiple jobs are running at the same time, all waiting for a worker to be IDLE, multiple jobs start using the worker at the same time. The reason was that first, the state of the worker is polled using /state - then, after some delay, it is reserved using the /start endpoint. Problem 1 was that there is a delay between checking and reserving - leading to a window of time where another job could do the same thing. Problem 2 is that once /start was used, there was nothing to stop the client from continuing, even if the worker was BUSY. This commit forgoes the /state endpoint, and just skips to trying /start - if the worker is IDLE, its instanly reserved, if its BUSY, the reponse is actually checked and nothing happens.
…iately
There is a problem where if the multiple jobs are running at the same time, all waiting for a worker to be IDLE, multiple jobs start using the worker at the same time. The reason was that first, the state of the worker is polled using /state - then, after some delay, it is reserved using the /start endpoint. Problem 1 was that there is a delay between checking and reserving - leading to a window of time where another job could do the same thing. Problem 2 is that once /start was used, there was nothing to stop the client from continuing, even if the worker was BUSY. This commit forgoes the /state endpoint, and just skips to trying /start - if the worker is IDLE, its instanly reserved, if its BUSY, the reponse is actually checked and nothing happens.
Change-type: patch