MA
Значит питоний драйвер не драйвер!
или tarantool.connectmesh неправильный метод, непонятно
или tarantool.connectmesh неправильный метод, непонятно
это какой драйвер?
Size: a a a
2020 December 04
DS
он автоматом мастер не определяет
DS
это пул коннектов к роутерам как я помню задумку
SK
он автоматом мастер не определяет
а как же быть?
SK
соединяться к каждому по очереди, пока в статусе не окажется мастер?
AK
соединяться к каждому по очереди, пока в статусе не окажется мастер?
Например, использовать прокси с внешним координатором который подставляет каждый раз при соединении правильный адрес мастера (мастеров)
DS
там дискавери не помню подвезли
ИЛ
вечер добрый. а вот такой вопрос. во время работы моей функции в файбере(без явных и неявных yield-ов), тнт будет принимать и ставить в очередь новые запросы? и как вообще планировщик работает в этом плане? сделал я fiber.yield, как скоро он обратно получит управление?
ИЛ
то есть условно что то вроде "запустился мой файбер, пока он работал пришло 100 запросов к базе, он сделал yield, запросы обработались и файбер получил управление обратно" или нет?
AK
то есть условно что то вроде "запустился мой файбер, пока он работал пришло 100 запросов к базе, он сделал yield, запросы обработались и файбер получил управление обратно" или нет?
В какой момент файбер получит управление снова, угадать не получится, однако промежуток между повторными получениями управления зависит от общего количества файберов и того, вызывают ли они yield
MA
вечер добрый. а вот такой вопрос. во время работы моей функции в файбере(без явных и неявных yield-ов), тнт будет принимать и ставить в очередь новые запросы? и как вообще планировщик работает в этом плане? сделал я fiber.yield, как скоро он обратно получит управление?
как минимум есть 2 треда: сетевой и транзакционный
за приём и декодирование запросов отвечает сетевой.
а дальше они все ставяся в очереди и выполняются по очереди, по мере переключения файберов
за приём и декодирование запросов отвечает сетевой.
а дальше они все ставяся в очереди и выполняются по очереди, по мере переключения файберов
ИЛ
как минимум есть 2 треда: сетевой и транзакционный
за приём и декодирование запросов отвечает сетевой.
а дальше они все ставяся в очереди и выполняются по очереди, по мере переключения файберов
за приём и декодирование запросов отвечает сетевой.
а дальше они все ставяся в очереди и выполняются по очереди, по мере переключения файберов
так, а сетевой yield-ит после каждого принятого запроса или может их пачкой ставить в очередь?
MA
так, а сетевой yield-ит после каждого принятого запроса или может их пачкой ставить в очередь?
пачками читает
можете прям по исходникам посмотреть
https://github.com/tarantool/tarantool/blob/master/src/box/iproto.cc#L995
можете прям по исходникам посмотреть
https://github.com/tarantool/tarantool/blob/master/src/box/iproto.cc#L995
ИЛ
да, пожалуй все равно придется в исходники идти
ИЛ
спасибо
ИЛ
а, еще вот что. fiber.sleep() в итоге отрабатывает как "проснуться ровно через" или "проснуться не раньше чем"?
AB
а, еще вот что. fiber.sleep() в итоге отрабатывает как "проснуться ровно через" или "проснуться не раньше чем"?
Не раньше чем
ИЛ
ок, спасибо
R
используйте cartridge pack docker. он производит правильные контейнеры
а можно чтото сделать чтобы он не образы собирал а делал Docker Файл из которого это можно собрать , а то дичькакаято получается