web-dev-qa-db-fra.com

Laravel les files d'attente ne fonctionnent pas

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
5
Punabaka Abhinav

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 

10
Mahdi Youseftabar

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
1
Haydar ŞAHİN

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
1
Jon McClung

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.

1
TipuZaynSultan

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

  • la jamais est ici la clé, car si aucun d'entre eux ne se déclenche, c'est peut-être parce que votre code de travail est modifié et que votre file d'attente doit être redémarrée.

Autre problème 2: la création de travail (constructeur) fonctionne, mais le gestionnaire de travaux ne se déclenche pas - parfois

  • lorsque (parfois) _ est vrai pour vous, il se peut que vos tâches qui ne sont pas déclenchées le soient parce qu'elles se produisent pendant une transaction, comme un 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:

  • votre travail envoie un courrier électronique à un utilisateur lorsque le paiement est effectué avec succès
  • votre paiement pourrait être réussi, ne pourrait pas être
  • en fonction du paiement réussi, vous annulez ou commettez

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.

0
amurrell