Processes

Recruiter process

Il processo recruiter é colui che si occupa di assegnare, al momento giusto, i job presenti in coda ai vari worker che sono in esecuzione.
E’ importante che una sola instanza del processo recruiter sia live in un determinato momento, ma lo sviluppatore non deve preoccuparsene in quanto il recruiter include al suo interno un meccanismo di muta esclusione, é quindi possibile eseguire più processi in contemporanea (ad esempio se si hanno più server identici, ognuno dei quali lancia la propria istanza di recruiter) senza che ci siano problemi di concorrenza.
Per maggiori informazioni riguardo a questa funzionalità guardare il capitolo relativo a Geezer
Il processo recruiter per funzionare ha bisogno di collegarsi ad un istanza di mongodb, é possibile specificare l’URI tramite l’opzione –target ${MONGOURI} (se non specificata il processo recruiter proverà a collegarsi a localhost:27017)
Se si vuole approfittare degli hook messi a disposizione dal processo recruiter é indispensabile passare al comando uno script php da includere, in modo tale che le funzioni definite dall’utente siano visibili. Questo può essere fatto tramite l’opzione –bootstrap
Per lanciare il processo recruiter utilizzare il seguente comando:
$ php vendor/bin/recruiter start:recruiter --target 127.0.0.1:27017

Per una lista completa delle opzioni lanciare il comando:

$ php vendor/bin/recruiter help start:recruiter

Worker process

Il processo worker é colui che si occupa effettivamente di eseguire un determinato job.
Al proprio avvio il processo worker comunica al processo recruiter il fatto di essere disponibile ad accettare lavori.
E’ possibile eseguire più processi worker in contemporanea, ognuno di questi eseguirà un singolo job alla volta.
E’ possibile limitare un worker all’esecuzione di un solo specifico gruppo di lavori, questo é un metodo per poter gesitre in maniera blanda le priorità.
Il processo worker per funzionare ha bisogno di collegarsi ad un istanza di mongodb, é possibile specificare l’URI tramite l’opzione –target ${MONGOURI} (se non specificata il processo worker proverà a collegarsi a localhost:27017)
Ad eccezione di alcuni rari casi, il processo worker dovrà eseguire codice facente parte del progetto in cui viene incluso, é quindi indispensabile passare al comando uno script php da includere, in modo tale che le classi definite dall’utente siano visibili. Questo può essere fatto tramite l’opzione –bootrap
Per lanciare il processo worker utilizzare il seguente comando:
$ php vendor/bin/recruiter start:worker --target 127.0.0.1:27017 --bootstrap $APP_BASE_PATH/worker-boostrap.php

Per una lista completa delle opzioni lanciare il comando:

$ php vendor/bin/recruiter help start:worker

Cleaner process

Il processo cleaner si occupa di mantenere coerente lo stato della libreria.
Ad esempio un determinato worker potrebbe morire in maniera fatale durante l’esecuzione di un job, lasciando il job lockato e quindi non più eseguibile da altri.
Grazie al processo cleaner i job possono essere rimessi nella coda di esecuzione dopo un determinato periodo di stallo.
Il processo cleaner per funzionare ha bisogno di collegarsi ad un istanza di mongodb, é possibile specificare l’URI tramite l’opzione –target ${MONGOURI} (se non specificata il processo cleaner proverà a collegarsi a localhost:27017)
Per lanciare il processo cleaner utilizzare il seguente comando:
$ php vendor/bin/recruiter start:cleaner --target 127.0.0.1:27017

Per una lista completa delle opzioni lanciare il comando:

$ php vendor/bin/recruiter help start:cleaner

Logging

Come abbiamo visto nei paragrafi precedenti, é possibile lanciare i vari processi (recruiter, worker e cleaner) grazie allo script php vendor/bin/recruiter.
Lo script php vendor/bin/recruiter non fa altro che creare una istanza di Symfony\Component\Console\Application, registrare i vari Symfony\Component\Console\Command\Command (Recruiter, Worker e Clenaer Commands) ed eseguire l’applicazione symfony.
Lo script crea i comandi Recruiter, Worker e Cleaner iniettandogli un istanza di Psr\Log\LoggerInterface che logga su standard output. Nel caso in cui si desiderasse una diversa tipologia di Psr\Log\LoggerInterface bisogna includere questi comandi nella propria Symfony\Component\Console\Application in modo tale da poterli inizializzare iniettandogli il logger che si vuole.
<?php
// bin/my-command

use Recruiter\Geezer\Command\RobustCommandRunner;
use Recruiter\Factory;
use Recruiter\Infrastructure\Command\CleanerCommand;
use Recruiter\Infrastructure\Command\RecruiterCommand;
use Recruiter\Infrastructure\Command\WorkerCommand;
use Symfony\Component\Console\Application;
use Domain\MyLogger;

$logger = new MyLogger();

$application = new Application();

$application->add(RecruiterCommand::toRobustCommand(new Factory(), $logger));
$application->add(WorkerCommand::toRobustCommand(new Factory(), $logger));
$application->add(CleanerCommand::toRobustCommand(new Factory(), $logger));

$application->run();