ВГ
+ отлов падения воркера
Size: a a a
2020 June 25
ЛА
В aws sqs по дефолту работает политика, что если кто-то вычитал задачу, то она "обработана" и никто ее больше не видит, однако через таймаут она снова появится в очереди и получивший ее воркер в конце своего процессинга должен вручную задачу из очереди удалить
AS
в таком кейсе нужно ack делать после успешного выполнения задачи. Если приложение умерло, то задача остается в очереди
само собой, но если умерли до ack - то нужны "правила" по которым задачу можно снова давать в работу
ВГ
само собой, но если умерли до ack - то нужны "правила" по которым задачу можно снова давать в работу
это в любом случае нужно, при любой архитектуре.
ВГ
и самый сложный вопрос - это эти правила, а не устройство очереди.
EK
само собой, но если умерли до ack - то нужны "правила" по которым задачу можно снова давать в работу
в том-же кроллике если не получен ack, то через таймаут он сам пометит это сообщение как noack и сделает доступным для других косьюмеров
AS
в том-же кроллике если не получен ack, то через таймаут он сам пометит это сообщение как noack и сделает доступным для других косьюмеров
даже при политике at most once?
EK
даже при политике at most once?
при at most once - уже кладется ответственность на косьюмера, тогда можно при рековери паники делать noack
ЛА
На самом деле со skip locked можно не иметь никаких промежуточных статусов "в процессе" - воркер открывает транзакцию, делает select for update skip locked, обратывает и в конце обновляет статус сразу до "готово".
Если воркер упал в процессе выполнения, транзакция с ним откатывается и запись снова доступна для процессинга
Если воркер упал в процессе выполнения, транзакция с ним откатывается и запись снова доступна для процессинга
ВС
тут главное session_in_transaction_idle_timeout не забыть, чтобы коннекты в случае чего не текли
ЛА
тут главное session_in_transaction_idle_timeout не забыть, чтобы коннекты в случае чего не текли
Да, свелось к тем же таймаутам, но уже на уровне написанного ранее кода (бд)
AS
На самом деле со skip locked можно не иметь никаких промежуточных статусов "в процессе" - воркер открывает транзакцию, делает select for update skip locked, обратывает и в конце обновляет статус сразу до "готово".
Если воркер упал в процессе выполнения, транзакция с ним откатывается и запись снова доступна для процессинга
Если воркер упал в процессе выполнения, транзакция с ним откатывается и запись снова доступна для процессинга
если задача предполагает условное скачивание файла для обработки - звучит не супер гуд
ЛА
если задача предполагает условное скачивание файла для обработки - звучит не супер гуд
также как выше обсуждалось, только на уже готовых решениях.
Вместо жонглирования статусами, используем блокировки строк на запись.
Вместо жонглирования статусами, используем блокировки строк на запись.
ЛА
Вместо вручную написанных обработчиков упавших задач, естественный откат транзакции
VS
Всем привет!
Подскажите пожалуйста, кто работал с delve
Запускаю приложение для дебага через delve, вроде все ок
Но как подключаюсь через vscode - не работает, приложение не может найти хост базы данных (dial tcp: lookup db: no such host)
При этом, если пингануть из контейнера с приложением - все ок.
Кто-нибудь сталкивался с таким? Как решили?
Заранее благодарю!
Подскажите пожалуйста, кто работал с delve
Запускаю приложение для дебага через delve, вроде все ок
Но как подключаюсь через vscode - не работает, приложение не может найти хост базы данных (dial tcp: lookup db: no such host)
При этом, если пингануть из контейнера с приложением - все ок.
Кто-нибудь сталкивался с таким? Как решили?
Заранее благодарю!
V
Всем привет!
Подскажите пожалуйста, кто работал с delve
Запускаю приложение для дебага через delve, вроде все ок
Но как подключаюсь через vscode - не работает, приложение не может найти хост базы данных (dial tcp: lookup db: no such host)
При этом, если пингануть из контейнера с приложением - все ок.
Кто-нибудь сталкивался с таким? Как решили?
Заранее благодарю!
Подскажите пожалуйста, кто работал с delve
Запускаю приложение для дебага через delve, вроде все ок
Но как подключаюсь через vscode - не работает, приложение не может найти хост базы данных (dial tcp: lookup db: no such host)
При этом, если пингануть из контейнера с приложением - все ок.
Кто-нибудь сталкивался с таким? Как решили?
Заранее благодарю!
контейнер знает какой ip у db, локалка твоя -нет
DP
ну как бы да, именно на открытие этой чакры и расчитана задача.
жаль, что вариантов без паники что-то не придумывается
жаль, что вариантов без паники что-то не придумывается
VS
контейнер знает какой ip у db, локалка твоя -нет
хм, то есть он локально запускает приложение, а не делает attach к процессу в контейнере?
ЛА
Всем привет!
Подскажите пожалуйста, кто работал с delve
Запускаю приложение для дебага через delve, вроде все ок
Но как подключаюсь через vscode - не работает, приложение не может найти хост базы данных (dial tcp: lookup db: no such host)
При этом, если пингануть из контейнера с приложением - все ок.
Кто-нибудь сталкивался с таким? Как решили?
Заранее благодарю!
Подскажите пожалуйста, кто работал с delve
Запускаю приложение для дебага через delve, вроде все ок
Но как подключаюсь через vscode - не работает, приложение не может найти хост базы данных (dial tcp: lookup db: no such host)
При этом, если пингануть из контейнера с приложением - все ок.
Кто-нибудь сталкивался с таким? Как решили?
Заранее благодарю!
Прокинь порт отладчика наружу и стучись в локалхост.