Илья Чубаров, не говоря о том что есть абсолютно твердолобый и тупой вариант аля
class SuperDuperJob implements ShouldQueue
{
public function handle(){
$jobA = new JobA($this->initalData);
$jobA->handle();
$jobB = new JobB($jobA->nextData);
$jobB->handle();
...............
}
}
Илья Чубаров,
1. Ну насколько я помню вы можете расширять цепочку в момент обработки задачи.
2. Во вторых если у вас джобы создаются в изначальной джобе то вообще не понятно в чем проблемы - не смогли - не создали остальные, пошли на обработку такой ситуации
Илья Чубаров, перепутал c job chains. уже исправил. Chains это цепочка из задач которые будут выполняться последовательно, и в случае отвала какой либо задачи - отвалится вся цепочка.
Ипатьев, ага, городские показывали эти магические коробочки. и даже там была какая то шайтан магия. Хреновое настроение? Возникло желание похамить? Не стоит. Договорились?
Илья Чубаров, откуда такие ограничения? я честно говоря не прочитал сего в вопросе автора. Ну да ладно - у нас есть Chain Jobs в которые мы можем запихать любую последовательность и прописать что будет происходить при падении какой то задачи из списка. И обрабатывать эти цепочки в один поток.
Илья Чубаров, я задачу понял несколько иначе. есть джобы которые обращаются к какому то сервису и могут его задолбать и начать получать какой нибудь 429.
Ну первое банальное решение класть задачи от этого конкретного сервиса в конкретную очередь. И разбирать это одним воркером. И мы никогда не получим что у нас несколько воркеров полезут в один сервис и его задолбает. Оно будет их разбирать последовательно.
Второе решение, мы хотим зачем то запускать несколько воркеров на такие сервисы. Хотя вообщем то это не надо. Ну ок пишем свой миддлеваре - и свой rate limit который будет основаться скажем на основе количества обращений к сервису, ну который придется где вести - редис, мемкеш, база, файл. И откладывать его согласно каким то правилам.
Третье. Зачем нам fail table. мы можем отлавливать конкретную ситуацию когда мы ловим 429 - и шарашить delay().
У вас то какие проблемы были?
З.Ы. Если вы не нажимаете кнопку ответить - мне уведомление не сваливается.
Простите а зачем такие сложности? Выполнять определенный тип задач в один поток можно - просто отдав под это одну очередь и разбирать ее в один поток. Если нужно что то более сложное - то job middleware
не совсем понятно. что мешает вам создать 1 очередь где будут задачи с обращениями к сервисам с лимитами и разбирать ее одним воркером? или где то хранить количество обращений и откладывать задачи если лимит превышен?
Эмиль 🔥, ну не удачно вы набросали. Ни хрена не понятно что вы хотите выбрать. Выбрать все страны и если есть приджойнить к ним какого то пользователя из этой страны?
verygoodboy, try catch должен быть в сервисах - что бы вы могли выбросить дальше не просто RequestException а свой подтип эксепшна который будет указывать на то какой именно сервис отвалился или чего еще случилось. Дальше в зависимости от того что мы хотим, если мы хотим тупо вьюху вывести - можете у этого эксепшн захреначить метод render
Хрен тут чего не последовательно выполнится.