Struct background_jobs::ServerConfig

pub struct ServerConfig;

The entry point for creating a background-jobs server

ServerConfig is used to spin up the infrastructure to manage queueing and storing jobs, but it does not provide functionality to execute jobs. For that, you must create a Worker that will connect to the running server.

This type doesn’t have any associated data, but is used as a proxy for starting the background-jobs runtime.

use std::collections::BTreeSet;
use background_jobs_server::ServerConfig;
use failure::Error;

fn main() -> Result<(), Error> {
    let mut queue_set = BTreeSet::new();
    queue_set.insert("default".to_owned());

    let start_server = ServerConfig::init(
        "127.0.0.1",
        5555,
        1,
        queue_set,
        "example-db",
    );

    // Comment out the start so we don't run the full server in doctests
    // tokio::run(start_server)

    Ok(())
}

Implementations

impl ServerConfig

pub fn init<P>(
    ip: &str,
    base_port: usize,
    runner_id: usize,
    queues: BTreeSet<String, Global>,
    db_path: P
) -> Box<dyn Future<Error = (), Item = ()> + Send + 'static, Global>where
    P: AsRef<Path>,

Create a new background-jobs Server that binds to the provided ip with ports starting at base_port.

The smallest background-jobs server will bind to 3 ports. Each port serves a different purpose:

• base_port is the port that jobs are sent to the server on
• base_port + 1 is the port that the server uses to advertise which queues are available
• base_port + n is bound for an individual queue of jobs that the server pushes to workers.

This method returns a future that, when run, spawns all of the server’s required futures onto tokio. Therefore, this can only be used from tokio.

pub fn init_with_context<P>(
    ip: &str,
    base_port: usize,
    runner_id: usize,
    queues: BTreeSet<String, Global>,
    db_path: P,
    context: Arc<Context>
) -> Box<dyn Future<Error = (), Item = ()> + Send + 'static, Global>where
    P: AsRef<Path>,

The same as ServerConfig::init(), but with a provided ZeroMQ Context.

This can be useful if you have other uses of ZeroMQ in your application, and want to share a context with your dependencies.

If you’re running the Server, Worker, and Spawner in the same application, you should share a ZeroMQ context between them.