да , я хорошо понимаю это ...  везде  для этого на клиентах используются  паттерны сircuit breaker  и рейт  лимитеры....   но это не 404 ошибка    это должна быть спец ошибка -  попробуй позже ... я тоже против "удержания"

мы можем на время перезагрузки кода отдавать по HTTP другой ответ, не 404

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

вот о какой непоборенной вещи речь идет сейчас?

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

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

Чтобы не страдать от 404 (и аналогичных ошибок в других протоколах) достаточно init ролей написать без йилдов. Картриджные роли уже этому правилу слудуют.

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

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

но это все равно не очень спасает от переключение лидера...  предполагаю что  ratridge rpc leader_only  и vshard callrw  работают поразному...

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

если че чтото подобное используется прямо внутри роли в sharded_queue
https://github.com/tarantool/sharded-queue/blob/d80b3a4/sharded_queue/api.lua#L503

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

знал я одного такого

с ним все хорошо ?)

ну в принципе ожидаемо) т.к. ничего умнее двухфазного коммита в голову не идет

думал может чего упускаю

да, я видел работающую имплементацию двухфазки, прям вот по книжке все ровненько

ну двухфазку то я и сам делал, только делал для операций со спейсами по кластеру(drop, rename итд). ради такого то можно и с блокировкой всего кластера смириться. а вот когда надо сделать 2 условных апдейта - уже не то)