A 'client' represents something which submits work to the exchange
An exchange supports both 'client' requests (e.g.
Exposes the course-grained signature of pairing up jobs with worker subscriptions
Represents a match 'handler' which delegates out to other observers
Queries the exchange for a fiew of the pending jobs and subscriptions
Queries the exchange for a fiew of the pending jobs and subscriptions
the same as what a SubmitJob matcher would be, used to match work subscriptions
the same as a subscription matcher would be, used to match submitted job requsts
also as per a subscription matcher, this time matching the submissionDetails
Adds a special type for local exchanges.
Adds a special type for local exchanges. also exposing a means to observe jobs
Contains instructions/information specific to the job scheduling/matching
Represents anything which can be run as a job
Represents anything which can be run as a job
Json is a bit prescriptive, but that's going to cover 95% of the cases. Even if we have binary data, we can base64 encode it as an option.
If we end up doing a lot of data transfer, then we can change the job representation to be an akka Source
represents the job submission. As the job repo is heterogeneous, it could match anything really that's asking for work
The details contain info about the worker subscribing to work, such as it's location (where work should be sent to), and any arbitrary json data it wants to expose (nr of CPUs, runAs user, available memory, OS, a 'topic', etc)
The details contain info about the worker subscribing to work, such as it's location (where work should be sent to), and any arbitrary json data it wants to expose (nr of CPUs, runAs user, available memory, OS, a 'topic', etc)
Once a WorkSubscription is sent
the json matcher used against the 'job' portion of SubmitJob
the json matcher used against the additional 'details' part of SubmitJob
An exchange supports both 'client' requests (e.g. offering and cancelling work to be done) and work subscriptions