2017-07-04 10 views
0

Ich benutze Laravel 5.4 für eine Web-App, RabbitMQ für eine Nachrichtenwarteschlangenschicht und den Laravel Queue Worker. Ich habe zwei verwandte Themen:Laravel - Schema - MySql - Temporäre Tabelle "Existiert bereits"

temporäre Tabellen

Ich habe den folgenden Tabelle-Erstellungscode in meinem Konstruktor:

Schema::create('tmp_products', function (Blueprint $table) { 
      $table->temporary(); 
      $table->integer('id'); 
      $table->string('alias',  255); 
      $table->string('include', 255)->nullable(); 
      $table->string('exclude', 255)->nullable(); 
     }); 

Beachten Sie die Verwendung von

$table->temporary(); 

Wenn mehrere Instanzen dieses Prozesses werden gleichzeitig ausgeführt. Ich erhalte den folgenden Fehler:

Zuerst dachte ich, die Tabelle könnte nicht temporär sein, aber ich sehe die Tabelle in MySQL Workbench nicht, also ist es unwahrscheinlich.

Möglicherweise scheinen mehrere Prozesse den Verbindungsstatus zu teilen (da temporäre Tabellen sitzungsspezifisch sind). Der Code wird als Laravel php artisan queue:worker Befehl ausgeführt, der von supervisord (mit numprocs=3) verwaltet wird, und ich kann in Htop sehen, dass es drei Prozesse mit eindeutigen PIDs gibt, also verstehe ich nicht, wie sie den Verbindungsstatus teilen können.

Queue - Fehlgeschlagene Jobs

Was ist interessanter ist, dass ich die Warteschlange Arbeiter mit der Flagge --tries=0 (dh nicht Wiederholungs Verarbeitung von Nachrichten) laufen, so dass nach der oben Ausnahme innerhalb der job->handle() Methode ausgelöst wird Die Nachricht sollte sofort in die Laravel-Tabelle failed_jobs übertragen werden, aber was ich sehe, ist eine Endlosschleife von Ausnahmen, und die Nachricht verlässt niemals die Warteschlange.

Also ich denke, meine Fragen sind:

  1. Wie kann queue:worker Prozesse Anteil db-Verbindungszustand
  2. Warum diese besondere Szenario andernfalls Nachrichten stoppen, während sie tun wie erwartet ausfallen, wenn ich ausdrücklich throw new Exception(); in meinem Griff() Funktion

Jede Hilfe wird geschätzt.

Danke,

EDIT: habe ich herausgefunden, warum die andernfalls Jobs die failed_jobs Tabelle Eingabe nicht wurden. Wenn Sie die Einstellung --tries=0 auf Null setzen, werden die Jobs scheinbar für immer ausgeführt. Setzen Sie es auf 1, um es zu reparieren.

UPDATE: Der gleiche Fehler tritt auf, wenn rohen PDO mit:

$pdo = DB::connection()->getPdo(); 
$pdo->exec("CREATE TABLE tmp_products (id INT NOT NULL, alias VARCHAR(255) NOT NULL, include VARCHAR(255) NULL, exclude VARCHAR(255) NULL, PRIMARY KEY (id));"); 
+0

Versuchen Sie debug (mit xdebug oder phpdbg) und sehen, was eigentlich geht, was Verbindung/Fahrer im Einsatz. Es sieht wie eine Fehlkonfiguration aus. – pinepain

Antwort

0

ok ich es herausgefunden. Ich habe völlig missverstanden, wie die Laravel-Arbeiter arbeiten. In meinem Hinterkopf nahm ich an, dass sie wie Apache arbeiten - einen Arbeiter für jeden Job im Hintergrund hervorbringen - und jeden Arbeiter vernichten, wenn er fertig ist. Das ist nicht der Fall.Jeder Worker überwacht die Warteschlange, wartet und verarbeitet Jobs seriell. Es erstellt keine DB-Sitzung für jeden Job neu.

Übrigens bedeutet dies, dass derselbe Fehler einen einzelnen Worker im zweiten Job, den er verarbeitet, betreffen kann.

Also die temporäre Tabelle von meinem vorherigen Job existierte immer noch für den nächsten Job. Jetzt überprüfe ich einfach, ob die Tabelle existiert nicht neu erstellen.

Dank

Verwandte Themen