Laravel les files d'attente ne fonctionne pas

pour l'utilisation de la file d'attente vous si le travail :

.env fichier, vous devez changer queue_driver de synchronisation de base de données,
afin de l'ouvrir .env et assurer le suivi

queue_driver=database

après cela, vous devez créer une file d'attente de table dans votre base de données de l'artisanat de commande :

php artisan queue:table
php artisan migrate

et enfin, vous devez exécuter votre file d'attente avec php artisan queue:listen ou php artisan queue:work

OriginalL'auteur Mahdi Youseftabar

Mise à jour pour Laravel 5.7:

Dans .env, ensemble QUEUE_CONNECTION=database alors qui a distribué des emplois aller pour le pilote de base de données.

Alors:

 # 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

OriginalL'auteur Jon McClung

Accepté la réponse a été un problème pour moi, mais j'ai aussi de la plaie sur cette question pour les 2 autres problèmes similaires que j'ai résolu, et peut-être aider d'autres personnes qui se retrouvent ici.

Autre problème 1: création d'emplois (constructeur) fonctionne, mais l'emploi gestionnaire n'a pas de feu jamais.

• la jamais est la clé ici, car, en règle générale, si aucun n'est jamais le feu, il pourrait être parce que le code du travail est modifié et votre file d'attente doit être redémarré.

Autre problème 2: création d'emplois (constructeur) fonctionne, mais l'emploi gestionnaire n'a pas de feu parfois.

• quand parfois est vrai pour vous, alors il se peut que votre emplois qui ne sont pas de tir sont parce qu'ils sont qui se passe au cours d'une transaction, comme un DB::beginTransaction.

En supposant que je voulez le travail d'incendie même lors d'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 PAS le faire à moins que vous voulez à feu de votre emploi et de la force de la restauration. Ma situation est unique du fait que mon travail envoie des e-mails sur des erreurs FATALES, je tiens à feu parce que j'ai une erreur de briser le processus de toute façon (rollback va arriver et est imprévue due à l'erreur non interceptée).

Voici une situation où vous n'auriez pas envie de le faire:

• votre travail envoie un email à un utilisateur lorsque le paiement est validé
• votre paiement pourrait être couronnée de succès, n'a pas pu être
• selon le succès de paiement, vous rollback ou de commettre

Vous devez structurer votre envoi à arriver APRÈS la restauration ou de commettre.
Je n'ai pas ce luxe pour mon travail parce qu'il se passe quand je ne peux pas prédire (erreur FATALE). Mais si vous avez le contrôle sur elle, comme en sachant que votre paiement est réussie, expédition après que vous avez commis, ou de sortie tous les niveaux de transactions!

Je ne suis pas sûr du comportement de déclenchement d'un emploi alors que dans la transaction, et puis reculer ou de s'engager. Il pourrait être contourné si il ne fonctionne pas correctement par l'ajout d'un retard, mais qui semble peu fiable (deviner à combien de temps d'attente), sauf si elle a un retard important.

OriginalL'auteur amurrell