В моем есть возможность повесить обработку на файл коннекте или отработать фейл
https://github.com/tarantool/tarantool-java/blob/f32bafa8e4de65d858d8c07c7a9d73a9a7055ca3/src/main/java/org/tarantool/TarantoolClusterClient.java#L152-L160 https://github.com/tarantool/tarantool-java/blob/f32bafa8e4de65d858d8c07c7a9d73a9a7055ca3/src/main/java/org/tarantool/TarantoolException.java#L54-L71
BTW, там еще отдельно schema error хендлится. Там нужно повторить после того, как обновил схему.
Кстати, обновление схемы во время выполнения запросов,насколько частый кейс в реальных системах?
Раньше так делал net.box. До версии 1.10. Это приводило к тому, что когда по сети выполнялся package.reload, это приводило к ddl, изменению версии схемы и тихому ретраю запроса. В итоге инстанс мог релоадиться по 5-10 раз подряд. (Спасибо ещё, что прекращалось). Вообще на любую политику ретраев, даже на селекты, можно придумать пользовательский сценарий, где это стрельнёт. Поэтому неуправляемые ретраи это зло и подводные мины. Правильный подход — указывать политику с самим запросом. Причём стоит учитывать тот факт, что если от вас запрос вылетел, то он мог быть исполнен на базе, а ошибка вам могла дойти в искажённом виде.
ретраить должен твой модуль скорее всего
Только после обрыва коннекта и при ошибках отправки (не всех), кмк
Проверка schema id идет до выполнения запроса (по крайней мере, сейчас). Надо бы найти, что именно менялось.
Обсуждают сегодня