This schema summarize what going on with the solver-woker.
graph TD
A[Scheduler] -->|job1:request| B(Solver-worker)
A[Scheduler] -->|job2:request| B(Solver-worker)
B --> |job1:request with plat1,plat2|C
B --> |job2:request with plat1|C
C{Distrib by platform}
subgraph Solver-service
C -->|job1:plat1| D[worker1]
C -->|job1:plat2| E[worker2]
C -->|job2:plat1| F[worker3]
C -->...........
C -->|.....| G[worker n]
end
The solver-worker request for jobs to the scheduler with some capacity (--capacity). The solver-worker spawns a solver-service by setting the number(--internal-workers) of process which the solver-service can handle at once. A job request could have more than one platform for solving. A job request is split up in one request(job) per platform.
This PR fix the conflict between
--capacity
and--internal-thread-worker
of solver-service introduce by the PR https://github.com/ocurrent/solver-service/pull/22.This schema summarize what going on with the solver-woker.
The solver-worker request for jobs to the scheduler with some capacity (--capacity). The solver-worker spawns a solver-service by setting the number(
--internal-workers
) of process which the solver-service can handle at once. A job request could have more than one platform for solving. A job request is split up in one request(job) per platform.@mtelvers @tmcgilchrist