Для подключений к базе комментарий тоже актуален?
т.е., для быстрого переподключения я могу перед исполнением задачи добавить
Yii::$app->set('db', Yii::$app->getComponents()['db']); ?

Yii::$app->set('db', Yii::$app->getComponents()['db']); - создаёт новое подключение, но не закрывает предыдущего.

Решение конечно недоработанное, (based on comment ) но для случая, когда запросы только на чтение думаю подойдёт, если вдруг кому-то пригодится, или кто-то может прокомментировать, отпишусь как я в итоге сделал.
` use Yii;
use yii\base\Object;
use yii\db\Exception;
use zhuravljov\yii\queue\Job;
abstract class DBJob extends Object implements Job {

public static $name = "job name";
protected abstract function actualAction();

public function run() {
    echo "executing job " . static::$name . " \n";
    $time = microtime( true );
    try {
        $this->actualAction();
    } catch (Exception $e) {
        $this->reconnect();
        $this->actualAction();
    }
    echo ' > done ' . static::$name . ' (time: ' . sprintf( '%.3f', microtime( true ) - $time ) . "s)\n";
}

protected function reconnect() {
    echo " > > reconnecting to db\n";
    Yii::$app->db->close();
    Yii::$app->db->open();
}

} `
в итоге, Job ы наследующие от DBJob, упираясь в dbEception, будут повторены, после переподключения, и повторная ошибка уже не ловится, т.е. должна будет попасть в лог, как если бы небыло этой обёртки. (не тестировал ещё)

Я сделал бы через Queue::EVENT_BEFORE_WORK:

class ReconnectBehavior extends Behavior
{
    public function events()
    {
        return [
            Queue::EVENT_BEFORE_WORK => function () {
                try {
                    Yii::$app->db->createCommand('SELECT 1')->execute();
                } catch (\Exception $e) {
                    Yii::$app->db->close();
                    Yii::$app->db->open();
                }
            },
        ];
    }
}

Но это все костыли. Есть мысль запускать задания в отдельных дочерних процессах, чтобы основному процессу воркера оставить только опрос очереди.

Related #18.

Сделал так, чтобы задания выполнялись в отдельных дочерних процессах, а воркер только опрашивал очередь. Это должно решить проблемы с отваливающимися сокетами в компонентах db, mailer и прочих, где это актуально. Потестить можно из ветки master.

@zhuravljov выполнение заданий в дочерних процессах это тупик, т.к. на каждый таск тебе нужно проинициализировать приложение целиком, это очень сильно гасит производительность

@russianlagman это опция. Хотите обслуживать сокеты, и следить за утечками памяти самостоятельно - отключайте isolate-режим. И почему тупик? С таким же успехом тупиком ошибочно можно обозначить все, что уровнем выше ассемблера. Требует больше ресурсов и гасит производительность.

Надо бы раскрыть этот момент в доке. Много времени потратил на профилирование, почему при переносе кода в джобы производительность упала на порядок.

Сталкиваюсь с такой же ошибкой, через N часов простоя CLI просто перестает отвечать, в MYSQL вижу что коннект с пользователем для YII просто оборвался, после нажатия на ENTER и вываливается ошибка "General error: 2006 MySQL server has gone away", все это происходит в isolate=1 режиме. В isolate=0 все работает отлично по несколько дней. Mysq wait_time = 28800, задания приходят раз в день.

Я до конца так и не понял, если коннект инициализируется в воркере и потом просто отдается каждому воркеру, то он будет неизбежно отваливаться каждый раз по окончании тайм-аута.