Привет собссно есть задача сделать некую структуру чато-подобную с реквест-респонзами между клиентом и сервером по условно постоянно поднятому каналу.

Как это сделать на вебсокетах вопросов в общем то нет. всё просто. там у спринга есть некий хендлер который каждый раз пробегает когда что то приходит с фронта, ну и наоборот - просто постим ивент в сессию вебсокетовую и фронт его получает..

тепреь с лонг поллингом -- допустим я возвращаю футуру контроллером, теперь у меня цепляется клиент открывает хттп подключение и....
и что? у меня пробегает код и ничего. не пойму никак куда и что мне вкарячить чтоб он ждал ответа и когда ответ готов он его получал (или не получал).

или я чот туплю.

Petro123andreykaT,
Обычный polling проще. В js таймер и запрашивай сервер каждые 15 сек.
проще. но скважность 15 сек это долго.
делать 2 секунды это дикий оверхед будет если клиентов вдруг станет больше.

вадяandreykaTКак это сделать на вебсокетах вопросов в общем то нет. всё просто.т.е. ищем приключения....
не все клиенты умеют вебсокеты это раз. два с вебсокетами возни в других местах есть. в т.ч. при тухлом интернет коннекшене. а так да вс тут выигрывает.

неее. там другая тема. там у тебя поднимается хттп сессия и висит скажем 10 сек потом приходит респонз 200-тка (скажем пусто). следом сразу же у тебя поднимается хттп сессия и снова так же висит 10 сек и возврат 200. потом сразу же снова поднимается хттп сессия и висит теперь уже 5 секунд потому что на пятой секунде происходит на бэке какое то событие которое генерит сообщение которое и приходит в хттп респонзе, следом снова поднимается хттп сессия на следующие 10 сек (если ничего не случится. или меньше - если случится).

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

если же мы делаем просто реквесты каждые 15 секунд, то этот самый промежуток неполучения у тебя будет уже в худшем случае 15 секунд.

Petro123andreykaT,
Не мудри.
При long сессия висит. При не long сессия не висит.
Но частота опроса одинакова.
И сессию новую не надо создавать.
Что замудрил то?

при лонге сессия висит или до максимального срока или до наступления события (при котором она закрывается). это главная разница между просто тиканьем по циклу.

собссно это главное преимущество перед просто дерганьем эндпойнта по таймеру

так ну лонгполлинг - это один из подходов для ПОЦ. я смотрю все варианты.

мне больше всего нравится та тема с юнидирекшинал вебсокет нотификациями.

Leonid KudryavtsevPetro123Соединения то открытыми держим.
Х.з.
это скорее нагрузка на роутеры/инфраструктуру. Но и то не понятно, что дешевле: или держать открытыми или все время заново переустанавливать.

Для сервера:
При обычных сокетах - может быть проблема по кол-ву thread на сервере. При NIO - должно быть фиолетово.
простите, расшифруйте плиз НИО.

я знаю что такое нио, я не понял какое отношение это имеет к обсуждаемым вебсокетам и длинным хттп реквестам. вот и переспросил.

...продолжаю копать... чот я туплю с этими футурами и ивентами.

допустим... юзер по лонгполлу зацепился к бэку на 10 сек. висим 10 сек. тут на 5-й секунде происходит евент и в футуру заворачиваем сообщение. отдаем. всё хорошо. следом коннекшн закрывается.. следом появляется новое сообщение для юзера. но он еще не успел переподключиться по лонгполлингу заново. и тут сюрпрайз - стартует новая сессия.. и... как ему узнать что для него появилось новое сообщение?
вариант а) -- после реестаблиша хттп сессии - пулим базу - находим новое анрид анделиверед мессадж - возвращаем. все рады.
плюсы решения - оно работает.
минусы решения - оно жрет ресурсы базы, т.к. каждый раз стучаться каждые 10 сек в базу селектом - там себе барахло.
вариант б) -- неким чудом мы держим сообщение в очереди на предмет доставки листенеру и соответственно когда поднимается хттп коннекшн мы сразу же из очереди его отдаем сервису что вернет его контроллеру.
плюсы решения - ну.. мы не стучимся в базу. это здорово.
минусы решения - как это сделать? прикручивать MQ?? а без этого можно как-то обойтись?

я тут нашел вроде как реализацию МК на редисе.. ранее работал с редисовским пабсабом но вот с очередью нет.. я так понимаю из коробки этого нету и нужно самому руками писать. никто не сталкивался?

вадяandreykaTне все клиенты умеют вебсокеты это раз.интересно что за клиенты у тебя, что не умеют?
andreykaTдва с вебсокетами возни в других местах естьпереисли, плиз
andreykaTв т.ч. при тухлом интернет коннекшенечто подразумевается под тухлым?
это означает что у тебя хост пингуется с потерями пакетов до 75%

Petro123andreykaTследом коннекшн закрывается..не путай коннек ajax и сессию юзверя.
я говорю о физическом уровне тцп, когда хттп коннекшн открывается с посылкой всех хадаров и тп. а потом закрывается с возвратом всего пайлоада.

этот вариант тоже рассматривается. я все варианты подбираю. просто в отличии от ВС к ЛП есть вопросы. с ВС всё понятно. там любой школьник справится.