exchange
Something which can create instances of T from Dispatch details to send to REST services (or wherever, but that's the intent)
A 'client' represents something which submits work to the exchange
A client-side representation of a SubmitJob / WorkerDetails match produced by an Exchange, created
An exchange supports both 'client' requests (e.g.
An exchange supports both 'client' requests (e.g. offering and cancelling work to be done) and work subscriptions
Exposes the course-grained signature of pairing up jobs with worker subscriptions.
Exposes the course-grained signature of pairing up jobs with worker subscriptions.
In practice there is just one implementation which evaluates the json matchers of the SubmitJob and WorkSubscription, but in theory you could implement any test to pair up jobs with work subscriptions
Represents a match 'handler' which delegates out to other observers
Queries the exchange for a view of the pending jobs and subscriptions
Queries the exchange for a view 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 requests
also as per a subscription matcher, this time matching the submissionDetails
chooses all the eligible (matched) workers on the exchange.
chooses all the eligible (matched) workers on the exchange. The assumption is the work will be sent to all the workers, though the requesting client will just return the first to finish
A SelectionMode determines which matched candidate(s) are chosen from an Exchange selection.
A SelectionMode determines which matched candidate(s) are chosen from an Exchange selection.
For example, if there is a pool of 10 work subscriptions, and a job is submitted which matches three of them, the SelectionMode determines which of the three are selected.
Typically just the _best_ one of the list is chosen for some configurable meaning of _best_, though it could select any number of work candidates.
Adds a special type for local exchanges.
Adds a special type for local exchanges. also exposing a means to observe jobs.
This way the 'MatchObserver' provided to the Exchange is accessible. Also, as convenient as it is to provide multiple implementations of a generic Exchange (i.e. local and remote), It's useful to know the intent when wiring together components (e.g. so we don't have a REST service configured which just sends exchange requests to itself)
The SubmissionDetails is the ansillary information submitted with a job request.
The SubmissionDetails is the ansillary information submitted with a job request.
Where a typical REST endpoint would just take some POSTed json request, the SubmitJob requests wraps that json together will some information intended for the Exchange in order for it to match the job with a worker.
The SubmissionDetails is that additional information to act as instructions/information specific to the job scheduling/matching. It contains:
a hold-all json blob which can include any details a client request wishes to expose to potential workers. It could contain e.g. session information, the submitting or 'run-as' user, etc.
an instruction on which/how to select matching work subscriptions as an opportunity to filter on best-fit
if true, the job submission to the exchange should block until one or more matching worker(s) is found
the json criteria used to match work subscriptions
should the 'workMatcher' not match _any_ current work subscriptions, the SubmitJob is resubmitted with the 'orElse' criteria
Represents anything which can be run as a job, together with some submissionDetails which are used to instruct the Exchange.
Represents anything which can be run as a job, together with some submissionDetails which are used to instruct the Exchange.
Where a basic REST endpoint would typically be POSTed some json data, a 'SubmitJob' acts as an envelope for that 'job', pairing it with some additional SubmissionDetails.
The Exchange can then use both the job and submission details to match work with pulling work subscriptions based on the criteria/selection mode/etc specified by the submission details and work subscription.
represents the job submission. As the job repo is heterogeneous, it could match anything really that's asking for work
The ability to create SubmitJob instances from some value
Updates the subscription's work details if the 'condition' matches
Updates the subscription's work details if the 'condition' matches
The condition can be used to assert the update it is about to perform. For instance, it could be used to check the value 'version == foo' to ensure it's updating the latest version, or to only add/remove values should some other condition hold. Basically I'm just trying to say the same thing over and over again.
the subscription to update
the condition to check on the current WorkDetails data before performing the update
the changes to apply
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
represents a json blob of data which can be matched by SubmissionDetails match criteria to filter out workers
the criteria used to match submitted job data
the criteria used to match submitted jobs' submission details
If non-empty, changes to the number of work items requested for this subscription will be performed on the referenced subscriptions
just chooses one of the eligible workers
A client-side representation of a SubmitJob / WorkerDetails match produced by an Exchange, created
by the AsClient which made the initial request.
The workflow is:
1) Some custom request object 'Foo' -> 2) a 'SubmitJob' containing the json form for 'Foo' -> 3) a call to an Exchange with the SubmitJob -> 4) a reply w/ a match from the exchange -> 5) the exchnage client taking initial Foo, SubmitJob, and MatchDetails/WorkerDetails from the match response and producing a Dispatch 6) an implicit AsClient typeclass using the info in 'Dispatch' to make some request, presumably against the worker defined in 'WorkerDetails'
the original request type before it was serialised into json in the submit job
the initial request object used to produce the SubmitJob
the SubmitJob instance which was produced from request request and sent to the exchange
the match details from the Exchange
the worker details matched to the SubmitJob