[−][src]Crate background_jobs
Background Jobs
This crate provides tooling required to run some processes asynchronously from a usually synchronous application. The standard example of this is Web Services, where certain things need to be processed, but processing them while a user is waiting for their browser to respond might not be the best experience.
Usage
Add Background Jobs to your project
[dependencies]
actix = "0.8"
background-jobs = "0.6.0"
failure = "0.1"
futures = "0.1"
serde = "1.0"
serde_drive = "1.0"
sled = "0.28"
To get started with Background Jobs, first you should define a job.
Jobs are a combination of the data required to perform an operation, and the logic of that
operation. They implment the Job
, serde::Serialize
, and serde::DeserializeOwned
.
use background_jobs::Job; use serde_derive::{Deserialize, Serialize}; use failure::Error; #[derive(Clone, Debug, Deserialize, Serialize)] pub struct MyJob { some_usize: usize, other_usize: usize, } impl MyJob { pub fn new(some_usize: usize, other_usize: usize) -> Self { MyJob { some_usize, other_usize, } } } impl Job for MyJob { type Processor = MyProcessor; // We'll define this later type State = (); type Future = Result<(), Error>; fn run(self, _: Self::State) -> Self::Future { println!("args: {:?}", self); Ok(()) } }
The run method for a job takes an additional argument, which is the state the job expects to use. The state for all jobs defined in an application must be the same. By default, the state is an empty tuple, but it's likely you'll want to pass in some Actix address, or something else.
Let's re-define the job to care about some application state.
#[derive(Clone, Debug)] pub struct MyState { pub app_name: String, } impl MyState { pub fn new(app_name: &str) -> Self { MyState { app_name: app_name.to_owned(), } } } impl Job for MyJob { type Processor = MyProcessor; type State = MyState; type Future = Result<(), Error>; fn run(self, state: Self::State) -> Self::Future { info!("{}: args, {:?}", state.app_name, self); Ok(()) } }
Next, define a Processor.
Processors are types that define default attributes for jobs, as well as containing some logic
used internally to perform the job. Processors must implement Proccessor
and Clone
.
use background_jobs::{Backoff, MaxRetries, Processor}; const DEFAULT_QUEUE: &'static str = "default"; #[derive(Clone, Debug)] pub struct MyProcessor; impl Processor for MyProcessor { // The kind of job this processor should execute type Job = MyJob; // The name of the processor. It is super important that each processor has a unique name, // because otherwise one processor will overwrite another processor when they're being // registered. const NAME: &'static str = "MyProcessor"; // The queue that this processor belongs to // // Workers have the option to subscribe to specific queues, so this is important to // determine which worker will call the processor // // Jobs can optionally override the queue they're spawned on const QUEUE: &'static str = DEFAULT_QUEUE; // The number of times background-jobs should try to retry a job before giving up // // Jobs can optionally override this value const MAX_RETRIES: MaxRetries = MaxRetries::Count(1); // The logic to determine how often to retry this job if it fails // // Jobs can optionally override this value const BACKOFF_STRATEGY: Backoff = Backoff::Exponential(2); }
Running jobs
By default, this crate ships with the background-jobs-actix
feature enabled. This uses the
background-jobs-actix
crate to spin up a Server and Workers, and provides a mechanism for
spawning new jobs.
background-jobs-actix
on it's own doesn't have a mechanism for storing worker state. This
can be implemented manually by implementing the Storage
trait from background-jobs-core
,
or the background-jobs-sled-storage
crate can be used to provide a
Sled-backed jobs store.
With that out of the way, back to the examples:
Main
use actix::System; use background_jobs::{ServerConfig, sled_storage::Storage, WorkerConfig}; use failure::Error; use sled::Db; fn main() -> Result<(), Error> { // First set up the Actix System to ensure we have a runtime to spawn jobs on. let sys = System::new("my-actix-system"); // Set up our Storage let db = Db::start_default("my-sled-db")?; let storage = Storage::new(db)?; // Start the application server. This guards access to to the jobs store let queue_handle = ServerConfig::new(storage).start(); // Configure and start our workers WorkerConfig::new(move || MyState::new("My App")) .register(MyProcessor) .set_processor_count(DEFAULT_QUEUE, 16) .start(queue_handle.clone()); // Queue our jobs queue_handle.queue::<MyProcessor>(MyJob::new(1, 2))?; queue_handle.queue::<MyProcessor>(MyJob::new(3, 4))?; queue_handle.queue::<MyProcessor>(MyJob::new(5, 6))?; // Block on Actix sys.run()?; Ok(()) }
Complete Example
For the complete example project, see the examples folder
Bringing your own server/worker implementation
If you want to create your own jobs processor based on this idea, you can depend on the
background-jobs-core
crate, which provides the Processor and Job traits, as well as some
other useful types for implementing a jobs processor and job store.
Modules
memory_storage | A default, in-memory implementation of a storage mechanism |
sled_storage |
Structs
Every | A type used to schedule recurring jobs. |
JobStat | A time-based overview of job completion and failures |
QueueHandle | A handle to the job server, used for queuing new jobs |
ServerConfig | The configuration for a jobs server |
Stats | Statistics about the jobs processor |
WorkerConfig | Worker Configuration |
Enums
Backoff | Different styles for retrying jobs |
MaxRetries | How many times a job should be retried before giving up |
Traits
Job | The Job trait defines parameters pertaining to an instance of background job |
Processor | The Processor trait |