Центрифуго

так его одну запустить только можно не?

с приватными каналами с laravel-echo дружит?

эхо сервер не нужен, или центрифуга, или эхо

не, типа как там реализовать такую же систему как там в echo?

https://github.com/LaraComponents/centrifuge-broadcaster такое?

Приветствую. Буду благодарен, если поможете. Хоть каким-то советом :) есть таблица1 у которой может быть много записей в таблице2. один ко многим. Сделал связь hasMany->belongsTo , и прописал необходимые условия, т.к. не все записи из таблицы2 подходят. все работает правильно. Теперь мне нужно соединить таблицу2 (те записи, которые уже вынул) и таблицу4 через таблицу3. Все они логически выстроены. Итого мне нужно забрать определенные данные из таблицы4. Сам sql запрос написал, все на join, все работает верно, как это перевести в модели - не знаю, на этом мои полномочия всё. 😄 Спасибо заранее!

Ну ты прям всю доку по отношениям прочитал ?

https://laravel.com/docs/8.x/eloquent-relationships#one-to-many

SOS, как такое возможно

ребята, есть вот такой проход по файлу
$reader->registerCallback($productTagPath, function ($reader) use ($current, &$i) {
   if($current <= $i){
       $product = $reader->expandSimpleXml();
       $i += 1;
       $this->storeProduct($product, $i);
       \Log::info('attempt= ' . $this->attempts  . ',read, i = ' . $i);
   }else{
       \Log::info('attempt= ' . $this->attempts  . ',skip, i = ' . $i);
       $i += 1;
   }

   return true;
});

attempts отвечает за то, какая попытка обработать сейчас актуальна(job->attempts())

и вот что я получаю в логах после первого обрыва(на фото)

каким образом attempts 1 вписался среди уже attempts = 2???

я так понимаю все дело в numprocs=3 в конфигурации supervisor, так как если ставлю один интанс, то все супер, никаких обрывов и непресказуемых выполнений?

решение - прочитать эту статью https://laravel.ru/posts/1187, все что выше описал возможно как раз из-за того, что «Второй проблемой является весьма странное поведение Laravel воркера — он обрабатывает одну и ту же(!!! Да, Карл, очереди тут такие очереди) задачу разными инстансами. «

есть кто может помочь проверить сайт на уязвимости и дать советы если что?

В целом коммент звучить немного бредово, от того что надо использовать БД для очереди до того, что одна джоба разными инстансами обрабатывается.
Продебажьте более глубоко. Вообще странно, что в вашем коде при том, что джоба сбросилась - нумерация &i осталась. Ощущение что она не сбросилась или еще что. Введите еще информацию в лог о считанном файле, чтобы понять где обрыв, какая инорфмация продублировалась или пропала.

посмотрю, попробую,спасибо!

+ вот эти параметры возможно что-то подскажут https://laravel.com/docs/7.x/queues#job-expirations-and-timeouts

https://ph4r05.deadcode.me/blog/2017/12/23/laravel-queues-optimization.html - вот обширная статья на эту тему

Статья про БД, а джобы с БД - не есть хорошо

Их надо или в кролика или редис пихать

ну раз есть такая возможность, то можно ведь использовать и должно бы нормально работать. С бд можно переходить попозже, уровень входа через бд ниже😉 да и наглядно в бд сразу

В общем я склоняюсь к тому, что да - работать из коробки должно нормально, поэтому скорее всего проблема в вашей настройке и реализации джобов.

ну так проблема такая не только у меня, есть же конкретное issue