A Job that runs the given actor (creates a new actor instance).
A Job that runs the given actor (creates a new actor instance).
The actor must:
$ - stop()
itself (e.g. via ActorContext.stop
once it's finished
$ - handle ActorJob.Cancel and stop
itself when it received this message
Base class for jobs, job execution is started via run()
.
Base class for jobs, job execution is started via run()
.
For actor jobs you can just use the ActorJob
.
Details regarding a job execution.
The actual execution of a certain Job.
Executes jobs, manages currently running jobs.
A JobManager is responsible for running jobs.
A JobManager is responsible for running jobs. It creates the infrastructure, checks locking etc. for job running
JobStartStatus classes are used to communicate the result of a job start request.
Represents Status of Import Jobs
Repository to manage job status in the database.
Repository to manage job status in the database. Write and Read Methods can be called with Consitency Level LOCAL_QUORUM to get consistent Job data from Cassandra. This is necessary to prevent the JobSupervisor from setting Finished Jobs to Dead Jobs
Checks if for jobs in state RUNNING there's a lock as well.
Checks if for jobs in state RUNNING there's a lock as well. If this is not the case, the job is considered to be crashed (because a job must regularly update the corresponding lock).
The job type, identified by its name, specifies a LockType.
The job type, identified by its name, specifies a LockType.
JobTypes do not override toString
so that there can more useful log output when
a jobType is just printed. When storing a reference to a JobType e.g. in C*, the name property
must be used instead of toString (like it's done for Enumerations).
JobUpdater is responsible finding running/pending jobs that have lost its lock and set them to status failed/dead JobUpdater tries to get latest JobStatusData to update status, so one can see the latest content of the dead job.
An Actor which helps to keep long running sychronous job tasks alive by updating the job lock periodically.
A Lock exists for jobType and jobId.
This repository manages locks for jobs syncronization in distributed environments.
This repository manages locks for jobs syncronization in distributed environments. To work every kind of job needs an unique identifier (jobType) and every job run an unique identifier (jobId) If a job acquires a lock, it will only get it, if there isn't already a jobId saved for that jobType. The jobId of the running job will be saved with a ttl to the lock table. A running job needs to renew its lock to show it's still active and not died.
We use Consistency Level Quorum to ensure that a Job is Locked or is not Locked. The CL makes the Lock mechanism more deterministic.
A LockType describes a lock used by a JobType (e.g.
A LockType describes a lock used by a JobType (e.g. JobType(stockFeed) can reference a LockType(stock)).
Supports shortcut to store the job status, can be mixed into Jobs.
Tries function max n times.