OD
interface BlockingRSocket {
void FireAndForget(Payload p):
Iterable<Payload> requestStream(Payload p)
}Size: a a a
2020 May 14
OD
итд
OD
тебе никто ж не запрещает создать собственный scheduler и делать все в следующем виде
DP
тебе никто ж не запрещает создать собственный scheduler и делать все в следующем виде
ну да, свои пулы мне никто не запрещает делать 😊
OD
Mono<Payload> requestReponse(Payload p) {
return Mono.fromSupplier(() -> {
// do my blocking stuff here
}).subscribeOn(Schedulers.boundedElastic());
}OD
вот и я о томже
DP
@OlehDokuka спасибо за пояснения!
OD
У нас в RSocket-RPC даже есть генератор
OD
для блокирующего кода
OD
который делает все то чтоя обьяснил
OD
потому может свободно тырить
OD
там даже есть bakcpressure через iterable
OD
весьма neat штука
OD
вообще всем рекомендую выкинуть ваш protobuf RPC over HTTP2 (a.k.a gRPC) и переехать на protobuf RPC over RSocket 😄
V
> Rsocket - он в первую степень для сервер-сервер взаимодействия, или клиент-сервер?
Для обох кейсов
может использоваться также хорошо как для так называемого edge-networ
состоящего из разного набора девайсов общающегося с твоим сервером
так и для сервер сервер
так как сам протокол являеться peer-to-peer
потому сервера могут свободно общаться по созданому соеденению друг с другом
+
это может быть ingress
представь кейс
что нужно опросить девайсы
или проадейтить что то
но клиент об этом не в курсе
типа мобилка или браузер
и вместо того что бы пулить сообщение (к примеру)
сервер может сам пушать данные
или например запрашивать данные
типа (а какой заряд телефона сейчас и тд)
понятное дело клиент может слать эту инфу с интервалом - но что если эта инфа нужно иногда
и не всегда
типа разовая акция
в таком случае клиентский код может обьявить API для хендлинга и сервер может запрашивать данные самостоятельно
Бенефит - клиент не может открыть серверный порт а при этом может вести себя как сервер (вот он peer-to-peer)
Для обох кейсов
может использоваться также хорошо как для так называемого edge-networ
состоящего из разного набора девайсов общающегося с твоим сервером
так и для сервер сервер
так как сам протокол являеться peer-to-peer
потому сервера могут свободно общаться по созданому соеденению друг с другом
+
это может быть ingress
представь кейс
что нужно опросить девайсы
или проадейтить что то
но клиент об этом не в курсе
типа мобилка или браузер
и вместо того что бы пулить сообщение (к примеру)
сервер может сам пушать данные
или например запрашивать данные
типа (а какой заряд телефона сейчас и тд)
понятное дело клиент может слать эту инфу с интервалом - но что если эта инфа нужно иногда
и не всегда
типа разовая акция
в таком случае клиентский код может обьявить API для хендлинга и сервер может запрашивать данные самостоятельно
Бенефит - клиент не может открыть серверный порт а при этом может вести себя как сервер (вот он peer-to-peer)
Разве через websocket нельзя опросить клиентов с сервера?
SS
1. хм, я немного не понимаю, про "просто в pom.xml поменял зависимость - и у тебя уже netty". Мы сейчас про какой фреймворк говорим? Спринг бут так не умеет, он чётко разделяет веб серваера для реактивного программирования и сервлетов.
2. я мог обходится без Mono/Flux, когда жил на Томкате, который использовал модель Поток-на запрос (в базовом случае). Но когда я перешел на нетти, который уже живет в евент лупе, мне нужна какая-то другая модель программирования, например, использованее Reactor Netty.
2. я мог обходится без Mono/Flux, когда жил на Томкате, который использовал модель Поток-на запрос (в базовом случае). Но когда я перешел на нетти, который уже живет в евент лупе, мне нужна какая-то другая модель программирования, например, использованее Reactor Netty.
1. про спринг. не секрет ведь как заменить embedded tomcat на jetty. и спринг бут так умеет. там даже undertow можно юзать при желании, я не пробовал кстате. может есть кто такой опыт имеет? поделитесь опытом плиз
2. опять же я про спринг приложение. без реактивности. возможно мы говорим о разном. если делать реактивное приложение - тогда и собсно писать код реактивный.это не мой случай.
2. опять же я про спринг приложение. без реактивности. возможно мы говорим о разном. если делать реактивное приложение - тогда и собсно писать код реактивный.это не мой случай.
OD
Разве через websocket нельзя опросить клиентов с сервера?
Конечно же можно) Вопрос в том что тебе всеравно прийдеться делать layout для твоих сообщений, потом API делать, потому придумывать кейс для стриминга)
OD
в итоге напишешь свой RSocket)
V
Конечно же можно) Вопрос в том что тебе всеравно прийдеться делать layout для твоих сообщений, потом API делать, потому придумывать кейс для стриминга)
А backpressure есть ли вообще место при взаимодействии с клиентом?