P
Ну заняты и заняты, не большая беда
Это беда, потому что в этом нету смысла, а ресурсы используются, но я попробую с брокером разобраться. Спасибо
Size: a a a
2020 October 26
GM
квик поверх io_uring, я надеюсь? Иначе 3 юзера в час не обработать 😄
quic вживую не видел 🤗 не могу сказать :) знаю что rsocket на нем типа может (или должен) :))
DP
Gerr Mes
quic вживую не видел 🤗 не могу сказать :) знаю что rsocket на нем типа может (или должен) :))
не, пока не может. Сначала квику надо стать не драфтом, а стандартом, потом его надо поддержать в нетти, а потом поддержать в р-сокете. Но когда-то будет, я думаю
AE
Это беда, потому что в этом нету смысла, а ресурсы используются, но я попробую с брокером разобраться. Спасибо
Какие ресурсы? Дескрипторы в системе?
P
Какие ресурсы? Дескрипторы в системе?
Сокеты
AE
Сокеты
Ну на уровне системы то понимаешь что там?
P
Ну на уровне системы то понимаешь что там?
Нет ))
Но если там дескрипторы, то все равно количество ограничено.
Но если там дескрипторы, то все равно количество ограничено.
AE
Нет ))
Но если там дескрипторы, то все равно количество ограничено.
Но если там дескрипторы, то все равно количество ограничено.
Это все не сложно подкручивается. Гугли "сервер с миллионом соединений"
P
Это все не сложно подкручивается. Гугли "сервер с миллионом соединений"
Ок, спасибо. Поищу
A
Ну s1 будет ожидать ответ от s2, а s2 от s5 и т.д.
А потом это будет разворачиваться в обратную сторону?
Я не хочу висящую цепочку микросервисов.
Я хочу из s1 отправить запрос на микросервис s2 и продолжить работу. Потом в какой-то момент получить ответ от любого другого микросервиса, проверить, что такой запрос был и послать на клиент ответ.
А потом это будет разворачиваться в обратную сторону?
Я не хочу висящую цепочку микросервисов.
Я хочу из s1 отправить запрос на микросервис s2 и продолжить работу. Потом в какой-то момент получить ответ от любого другого микросервиса, проверить, что такой запрос был и послать на клиент ответ.
Паттерн САГА? мы у себя в микросервисах ее заюзали
P
Паттерн САГА? мы у себя в микросервисах ее заюзали
Оо, загуглю. Как раз хотел услышать, как такое решается. Спасибо
A
Ruslan
Много микросервисов? Функционал какой?
Нее, всего 3, переводили документ в pending отправляли с 1-го сообщение в топик. Там же слушали другую очередь + deadletter от 2 и 3. Если вернулся успешный ответ от обоих переводили в active. Если в течении какого-то времени ничего не пришло или в deadletter нашли наш запрос - документ в rejected.
A
Нее, всего 3, переводили документ в pending отправляли с 1-го сообщение в топик. Там же слушали другую очередь + deadletter от 2 и 3. Если вернулся успешный ответ от обоих переводили в active. Если в течении какого-то времени ничего не пришло или в deadletter нашли наш запрос - документ в rejected.
хотя недавно читал в aws что deadletter вроде только дебага нужно юзать
R
С ростом микросервисов и функционала возникает ситуация, когда мозг системы размазан по микросервисам.
R
У разработчиков возникает соблазн выбросить платежное событие из модуля нотификаций. Я утрирую, но полагаю мысль поняли ))
AD
Коллеги, добрый день.
Использую Spring WebFlux и Кафка Реактор.
Задача обработать синхронный POST запрос, положить тело запроса в один топик Кафки.
Дождаться ответа в другом топике кафки. И вернуть этот ответ на Post запрос.
Пример кода здесь: https://pastebin.com/vkzLLs6K
Тело запроса успешно записывается в Кафку.
Слушатель Кафки успешно принимает ответ из Кафки.
Но POST запрос зависает на ожидании ответа из Кафки.
Вот на этой строчке:
.map(s -> {return fl.filter(strPair -> s.equals(strPair)); })
Для тестов использую один топик Кафки, что положил то и читаю из одного топика Кафки.
В чем я не прав? И как мне корректно дождаться ответа в другом топики Кафки в одном обработчике.
Использую Spring WebFlux и Кафка Реактор.
Задача обработать синхронный POST запрос, положить тело запроса в один топик Кафки.
Дождаться ответа в другом топике кафки. И вернуть этот ответ на Post запрос.
Пример кода здесь: https://pastebin.com/vkzLLs6K
Тело запроса успешно записывается в Кафку.
Слушатель Кафки успешно принимает ответ из Кафки.
Но POST запрос зависает на ожидании ответа из Кафки.
Вот на этой строчке:
.map(s -> {return fl.filter(strPair -> s.equals(strPair)); })
Для тестов использую один топик Кафки, что положил то и читаю из одного топика Кафки.
В чем я не прав? И как мне корректно дождаться ответа в другом топики Кафки в одном обработчике.
R
Зачем в одном?
R
Mono можно закинуть в мапу с ключем например по id запроса.
R
Для топика с результатами сделать листенер, когда в листенер прилетит ответ, то в нем должен быть id запроса, по нему из мапы достаем mono и ресолвим.