/ 
Garivini-0.002
River stage zero No dependents
/ Garivini::Client

NAME

Garivini::Client - Thin client for submitting jobs via Garivini

SYNOPSIS

use Garivini::Client;

# Client
my $cli = Garivini::Client->new(dbs => {
    1 => { id => 1, dsn => 'DBI:mysql:job:host=127.0.0.1', user => 'job',
        pass => 'job' } });
$cli->insert_job(funcname => 'hello', arg => 'world');

# Worker
use Gearman::Worker;
use JSON;

my $cli = Garivini::Client->new(dbs => {
    1 => { id => 1, dsn => 'DBI:mysql:job:host=127.0.0.1', user => 'job',
        pass => 'job' } });
my $worker = Gearman::Worker->new;
$worker->job_servers('127.0.0.1');
$worker->register_function('hello' => \&hello);
$worker->work;

sub hello {
    my $job = decode_json(${$_[0]->argref});
    print "Hello ", $job->{arg}, "\n";
    $cli->complete_job($job);
}

DESCRIPTION

Client used for issuing and removing jobs directly from a Garivini database. Used by client code directly, or indirectly via the supplied workers.

METHODS

new
$cli = Garivini::Client->new( %OPTIONS );

Creates a new client object. The only arguments it takes are for initializing a Garivini::DB object.

insert_job

Takes a hash of arguments and directly tosses a job into the a DB.

job

Hash describing a job

funcname

worker function name to execute the job

run_after

if given, offset from now for when to run job

unique

only run one job with this id (per database defined!)

coalesce

unimplemented. for running similar jobs together

arg

serialized blob payload.

flag

Optional; if set to 'shim', indicates that the job will be completed by a worker directly using Garivini::Client. If set to 'controller', the system will expect an Garivini::Controller worker to manage completion of the job.

insert_jobs
$cli->insert_jobs($jobs, $in, $flag);

Takes an array of arrays as jobs.

Jobs are defined as an array of arrays, in order: ['funcname', 'uniqkey', 'coalesce', 'arg']

Optionally $in is used for delaying job execution. All jobs will use the same value.

Optionally $flag is defined, as noted in "insert_jobs" above. All jobs will use the same value.

There is presently no way to do low latency submission for mass jobs, however they may still be executed via controller workers afterwards.

complete_job
$cli->complete_job($job_handle);

Takes a job handle and removes the job from the database. Job handles are received by Gearman workers, with the dbid and jobid's filled in.

reschedule_job
$cli->reschedule_job($job_handle, $when);

Reschedules a job for some time in the future, in case of temporary failure. You should call "failed_job" instead of this in most cases.

when

When to reschedule the job.

"never" sets the job to execute in 2038, long after civilization has been reclaimed. This leaves the job in the database for inspection, but will avoid retrying it.

"+360" would retry the job again in six minutes from now.

"1313572984" would retry the job at a specific unix timestamp.

failed_job
$cli->failed_job($job_handle);

Reschedules a job to retry in the future in case of a temporary failure. Applies a generic backoff algorithm based on the number of times the job has failed. Starts at two minutes and caps at one day.