Всем привет! Скажите пожалуйста, а progaudi.tarantool клиент для .net ещё поддерживается? Там последний релиз был в 2019м году.

Он работает хорошо и даже под большой нагрузкой. На кластере тарантула много пишем и читаем, всё отлично. Но есть одно но... до первой ошибки. Если что-то не так сданными (например, дубликат ключа или какое-то поле null), то строчка вида:

await _taskPrimaryIndex.Insert(task);

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

Запускаем всё под Linux на .netcore 2.1/2.2

Заранее спасибо

Ну так, очень вяло это всё поддерживается по разным причинам.

А с подобной проблемой не сталкивались, что вместо любых ошибок полное повисание? Проблема в том, что если оно так намертво повисает долго приходится анализировать руками что могло в конкретной вставке не так пойти

Одна из этих разных причин - я 2.5 года не использую тарантул в проде. Проблема известная, валидных воркэраундов я не дам. Там я начинал переписывать коннектор, но ковид и дети как-то отбили всё желание (нет особого стимула)

Есть репродьюсер?

В смысле репродьюсер?

Пример, на котором можно воспроизвести баг

Ребят, всем доброй ночи, кто не спит)
Вопрос: как можно в роли в init() объявить именованную очередь через rpc?

local res, err = rpc.call('sharded_queue.api', 'create_tube', { 'history_log' })

не робит ((
И как на  скрине - тоже. Разными способами пробовал - не получается. Прошу помощи, help :)

PS Я знаю почему не робит через rpc (нет функции создания очереди в return [тык] ), но как это обойти - вообще в голову не приходит. Это вообще возможно - создать именованную очередь на Cartridge в init роли?

PSS На скрине ломается именно после log.warn(' CREATE TUBE 1 ') , т.е. во время создания очереди - так отслеживал вызов)

Просто сделать индекс и попробовать сделать инсерт с любой ошибкой, самое простое - дубликат ключа. Т.е.

IIndex _taskPrimaryIndex = await taskSpace.GetIndex("primary");
await _taskPrimaryIndex.Insert(task);
await _taskPrimaryIndex.Insert(task);

Первый инсерт проходит, второй записывая ту же запись должен вернуть что-то Duplicare Key Exists но нет, он просто повиснет навсегда

Вообще, один полу-воркэраунд я нашёл. В методе SendRequest передаваемый timeout всегда null. Если его поставить хоть во что-то - то битые запросы будут возвращаться хотя бы с timeout и приложение не будет повисать навечно. Это ни как не отвечает на вопрос почему запрос завалился, но уже не надо рестартовать сервер.

В общем, я это починил. Пока сильно грязно, но постараюсь форкнуть и сделать МР, как только разберусь в формате ошибки которую возвращает тарантул.

Проблема в следующем, есть класс который называется ErrorResponsePacketConverter. Он, похоже, очень старый и вообще не понимает ошибки от тарантула. (тут очень примерно) так как тарантул не вернул нам хорошего ответа, а его ошибки мы не поняли, так как при парсинге ошибки всё время умираем на вот этой проверке:

if (length != 1u)
{
     throw ExceptionHelper.InvalidMapLength(length, 1u);
}

Клиент уходит в бесконечный ступор. Теперь, в случае ошибки, нам приходит в reader.ReadMapLength(); не 1, а 2... чтобы это не значило. Сделав доп ветку я смог таки из него получать вот такие вполне адекватные ошибки:

Tarantool returns an error for request with id: 82, code: 0x00008017  and message: LTuple field 6 type does not match one required by operation: expected stringR�?��?�ClientError���)/usr/src/tarantool/src/box/tuple_format.c�LTuple field 6 type does not match one required by operation: expected s.

Теперь ничего не повисает.

Мне кажется, что то, что я сейчас получаю - это ClientError вот отсюда:
https://github.com/tarantool/tarantool/blob/2.3/src/box/error.h
И мне надо правильно его из MsgPack извлечь. Но надо передохнуть чуть-чуть.

Ошибки можно почти нормально осознать, но бандлить своё приложение с той поделкой, что я сделал мне совсем не хочется, поэтому хочется поскорее пофиксить, выкатит в основную либу пулл реквест и получить всё как положено из nuget'a. Надеюсь поревьюить и запаблишить у вас время найдётся.

Всё, выкатил PR #152. Теперь ничего не повисает и ошибки показываются корректно

Простите, есть ли какой то фидбэк?

В лоб не получится, потому что вызов пытается менять clusterwide config, а он уже в процессе изменения когда работает init.
Есть несколько подходов:
* Проверять наличие очереди перед тем как туда класть/забирать и создавть если нет.
* Сделать файбер, который дожидается пока кластер станет configured, и тогда пытается вызывать create tube на одном из узлов.
* Добавить tube в clusterwide config.

Это означает, что формат ошибки поменялся

Я посмотрю, но только на выходных

Доброе утро! Мы ищем Middle Engineer в проект. Проект разрабатывается на Tarantool + Lua + работа с блокченом. Будем рады найти здесь специалиста. Подробности в личке. Благодарю.

@bigbes ^^ ?

Добрый день, мы проверили наличие пакета и не найдя его проверили у хозяйна пакета его типы сборок - CentOS 8 там нет. Сейчас мы общаемся по поводу возможного добавления CentOS 8 в сборку этого пакета