J'utilise les files d'attente de laravel pour commenter la publication sur facebook. Chaque fois que je reçois des données de facebook webhook, sur la base des détails reçus, je commente l'article. Pour gérer 100 réponses à la fois à partir de facebook webhook, j'utilise des files d'attente Laravel, afin qu'il puisse s'exécuter une par une .. J'ai utilisé le processus étape par étape comme indiqué dans https://scotch.io/tutorials/ pourquoi-laravel-queues-are-awesome
public function webhooks(Request $request)
{
$data = file_get_contents('php://input');
Log::info("Request Cycle with Queues Begins");
$job = (new webhookQueue($data)->delay(10);
$this->dispatch($job);
Log::info("Request Cycle with Queues Ends");
}
et ceci est ma structure de classe d'emploi
class webhookQueue extends Job implements ShouldQueue
{
utilisez InteractsWithQueue, SerializesModels;
private $data;
public function __construct($data)
{
$this->data = $data;
}
public function handle()
{
//handling the data here
}
}
J'utilise la fonction webhooks () de manière continue, tous les travaux fonctionnent simultanément mais pas en file d'attente, aucun des travaux ne sont stockés dans le tableau des emplois, j'ai donné du retard, mais cela ne fonctionne pas non plus, s'il vous plaît, aidez-moi, j'ai été essayant d'hier, mais aucun résultat.
Et ceci est mon journal laravel.log
[2017-02-08 14:18:42] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:44] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins
[2017-02-08 14:18:55] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:18:55] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:18:55] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:18:59] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:00] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:00] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:00] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends
pour utiliser la file d'attente, vous devriez travailler:
dans le fichier .env, vous devez changer queue_drive de la synchronisation à la base de données
après cela, vous devez créer une table de file d'attente dans votre base de données avec la commande artisan:
php artisan queue:table
php artisan migrate
et finalement vous devriez exécuter votre file d'attente avec php artisan queue:listen
ou php artisan queue:work
J'ai eu le même problème, si vous utilisez Laravel 5.7, utilisez ceci dans un fichier .env
QUEUE_CONNECTION=database
après effacer le cache de configuration comme ça
php artisan config:cache
Mise à jour pour Laravel 5.7:
Dans .env
, définissez QUEUE_CONNECTION=database
pour que les travaux distribués soient placés dans le pilote de base de données.
Ensuite:
# Creates a migration for the database table holding the jobs
php artisan queue:table
# Executes the migration
php artisan migrate
# Kicks off the process that executes jobs when they are dispatched
php artisan queue:work
Je vois que vous avez déjà une table de file d'attente.
Essayez d'exécuter php artisan queue:listen --tries=3
ou php artisan queue:work
etc.
Le travail en file d'attente ne permet d'exécuter qu'un seul travail par commande. Donc, s'il y a 20 tâches dans la table, vous devrez peut-être exécuter le travail en file d'attente 20 fois. C'est pourquoi vous pouvez exécuter la commande queue:listen
. Mais cela consomme beaucoup de CPU.
Sur le serveur, vous pouvez exécuter votre file d'attente d'écoute avec un maximum de 3 tentatives en arrière-plan. Puis CD
dans le répertoire de votre projet où réside le fichier artisan. Exécutez cette commande:
Nohup php artisan queue:listen --tries=3 > /dev/null 2>&1 &
Dans ce cas, les tâches seront automatiquement traitées en arrière-plan. Vous devez juste envoyer le travail. Et je vous recommanderais d’utiliser la table des tâches échouées. Si vous utilisez un listner de file d'attente en arrière-plan.
J'espère que cela t'aides.
La réponse acceptée était un problème pour moi, mais j'ai aussi abordé cette question pour deux autres problèmes similaires que j'ai résolus, et peut-être qu'ils vont aider d'autres personnes qui se retrouvent ici.
Autre problème 1: la création de travail (constructeur) fonctionne, mais le gestionnaire de travaux ne se déclenche pas - jamais.
Autre problème 2: la création de travail (constructeur) fonctionne, mais le gestionnaire de travaux ne se déclenche pas - parfois.
DB::beginTransaction
. En supposant que je veux que le travail soit déclenché même pendant une transaction, je peux le faire:
/**
* Create a new job instance.
*
* @return void
*/
public function __construct($errorInfo)
{
$this->errorInfo = $errorInfo;
// Queues won't run the handlers during transactions
// so, detect the level, and if it is not 0, rollback to force job handling
if (\DB::transactionLevel() != 0) {
\DB::rollBack();
}
}
MAIS NE LE FAITES PAS à moins que vous ne vouliez licencier votre travail et forcer le retour en arrière. Ma situation est unique en ce sens que mon travail envoie des courriers électroniques sur les erreurs FATAL. Je souhaite donc qu’il soit déclenché car j’ai quand même une erreur en interrompant le processus (la restauration est imminente et elle n’a pas été planifiée à cause d’une erreur non interceptée).
Voici une situation où vous ne voudriez pas faire ceci:
Vous devez structurer votre envoi après APRÈS une annulation ou une validation. Je n’avais pas ce luxe pour mon travail parce que cela arrive quand je ne peux pas prédire (une erreur FATALE). Mais si vous en avez le contrôle, par exemple si vous savez que votre paiement est effectué, envoyez-le après que vous ayez validé, ou quittez tous les niveaux de transaction!
Je ne suis pas sûr du comportement qui consiste à déclencher un travail pendant la transaction et à then annuler ou valider. On pourrait contourner le problème si cela ne fonctionnait pas correctement en ajoutant un délai, mais cela ne semble pas fiable (deviner combien de temps attendre) à moins que le délai ne soit important.