а как что? я без подколки, мне интересно

Интересует исключительно способ обнаружить отвалившийся узел

Или сабскрайбер в терминах очередей

все интереснее и интереснее :) а зачем его обнаруживать?

Ну например есть задача, мы его кинули в очередь, нам надо как можно быстрее понять что обслуживающий узел отвалился и отдать его другому обработчику

не надо

Надо ) задача обрабатывается время, все это время клиенты ждут

надо, чтобы свободный обработчик задачу забирал, и иметь их постоянно запущенными в достаточном количестве

Задача не свободна, его взял обработчик, и сдох

ну - ее же отпустит по таймауту, правда?

Обработка задачи занимает определенное время, исчисляется десятками секунд

Ну вот по таймауту, это дорого )

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

тогда у меня еще вопрос - почему очередь?

почему не поговорить с обработчиком напрямую?

Чтобы исключить сетевые/транспортные отвалы

я вот тоже в incaller все пытался очередь приспособить, но она так и не приспособилась, а приспособился service discovery и rest api

Чтобы исключить сетевые/транспортные отвалы

у вас очевидно синхронная обработка

очередь тут лишняя

Ну как вариант, если отвалилась сеть то с высокой вероятностью отвалится и обработчик, конеш

смотри

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

у теб есть клиент, который раз в N секунд получает из консула список обработчиков

и любому из них пытается отправить на обработку твой запрос

получилось - ждет ответа

если не получилось - пробует другой обработчик

осли обработчик сдох в процессе - запрос вернется с ошибкой (или по таймауту в криминальных случаях)

при чем тут очередь? ни при чем

Задача долго обрабатывается (~30 сек) все это время нужно ждать HTTP-ответ выходит?

а почему нет-то?

сокеты экономить?

Ну а если задач много сразу? Ага

много - это сколько?

Там же распределение Пуассона, надо считать

Статистики пока нету, это не на проде

не надо пока считать, надо порядок оценить

А нету ограничения на скорость генерации задач одним клиентом, если ввести отложенное время начала обработки например +10 сек на каждую задачу то один пользователь одновременно может 3 обрабатывать, с прогнозом 1к чел/сервер думаю это не больше 3к пока

Сокеты норм видимо

именно

я начинаю их в расчет брать только когда прогноз по ним - сотни тысяч. а по-настоящему на них экономить имеет смысл на миллионах

Но для исходящих соединений не 64к лимит?

Без всяких SO/REUSE_ADDR-сокетов

64K - это лимит сокетной адресации, там на порт два байта отводится. это можно обойти с помощью алиасных адресов на интерфейсе

но по факту - никогда еще не было нужно, кроме ка на тестах

у нас 30с исполняется задание

на 30К сокетов мы имеем возможность обработать 1К зданий в секунду

их точно есть столько?

у нас точно есть такая моща на обработчиках?

я к тому, что мы во что-то сильно раньше упремся

Эм, там время обработки нельзя уменьшить ) там запускается пропиетарный внешний тул от MS который можно запускать только в эксклюзивном режиме (нельзя пул создать, так как инстанцы блочат друг друга, вобщем жесть)

И там работает только переход в количество )

Всем привет

Ребят кто-нибудь пользовал echo для разработки REST API ?

Я сейчас использую fasthttp + gorm, мне советуют echo попробовать

для разработки rest api надо пользоваться swagger

потому, что это индустриальный стандарт

для разработки rest api надо пользоваться swagger

ну это для проектирования больше

я подозреваю, что это синонимы

ну и swagger мне сейчас не подойдет, потому как я API переписываю с другого языка

swagger он как Rational Rose когда-то, генерит каркас и описание

я подозреваю, что это синонимы

Скажите, пожалуйста, чем Вы генерируете документацию? Задавался этим вопросом пол года назад, хорошего решения не было.

не генерирую

Документация для слабаков 😄

привет всем в одном проекте не может быть больше одной функции main верно?

ну - мне достаточно swagger.yml

привет всем в одном проекте не может быть больше одной функции main верно?

не проверял :)

привет всем в одном проекте не может быть больше одной функции main верно?

я думаю может, просто не скомпилится

да проверить же 3 минуты

только непонятно, зачем

просто дело в том что хочу задачки по книге порешать и оформить их на гитхабе, каждая задача по сути будет в своей папке например глава 1 задача 1 задача 2 глава 2 задача 1 и тд

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

Я сейчас использую fasthttp + gorm, мне советуют echo попробовать

одно другому не мешает, у echo нету своей orm по этому можно и дальше использовать gorm и fasthttp можно с echo использовать, а из echo использовать роуты и какие-нибудь мидлвари

принято в проекте делать директорию cmd и в ней поддиректории сообразно приложениям

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

ты расскажи как это должно работать по твоему, а то ты пропустил этот момент

ты расскажи как это должно работать по твоему, а то ты пропустил этот момент

ну чтобы каждая задача отдельно запускалась )

ну чтобы каждая задача отдельно запускалась )

тогда зачем в main это все пихать?

тогда зачем в main это все пихать?

вот я и спросил у каждой задачи будет своя функция мэйн верно?

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

ну чтобы каждая задача отдельно запускалась )

go funcname() не устраивает?

сейчас вы опять плохому научите человека...