ŹR
Я не вижу смысла делать процесс, потому что на каждое сокет соединение и так есть процесс, который обрабатывается в параллель
Size: a a a
2019 September 02
ŹR
Все это выглядит как преждевременная оптимизация, которая занесет проблем как с тестированием так и с консистентностью бд
ŹR
У тебя залипает handshake изза записи в БД? Вангую что нет.
АН
ну да, писать без спавна процесса синхронно еще лучше, если это <50% от времени хендшейка.
VI
у меня один процесс на все приложение, который подписывается на Phoenix.Presence "presence_diff" и по ним решает, что надо делать INSERT – в редких эдж кейсах на одного клиента бывает несколько процессов (например, long poll fallback, ну или просто несколько вкладок человек открыл), поэтому сделано так, а не через мониторниг процессов
VI
немного не соответствует первоначальному описанию, но хотел его максимально по-проще сделать
ŹR
Это очень плохая архитектура совсем
VI
> У тебя залипает handshake изза записи в БД?
я еще даже на стейджинг не выкатился, так что пока не знаю )
я еще даже на стейджинг не выкатился, так что пока не знаю )
ŹR
Presence нужен чтобы в другие сокеты пихать дайджест по каналу
ŹR
Ты можешь без presence отслеживать для каждого пользователя и так что он присоединяется или отсоединяется
VI
могу, конечно, но там появляются дубли
ŹR
Ты же в базу пишешь - можешь разрулить дубли через upset
ŹR
Или как нибудь там
VI
и начать гадать, что это релаьный коннект дисконнект, или глюк long poll fallback'а?
ŹR
И что, presence с этим помогает?
VI
ага
ŹR
Найди плз код где он это разрулит - хочу глянуть
ŹR
Последний раз когда я туда смотрел - там не было такой магии
ŹR
Самое главное, что ты на presence подписываешься в коллбэке на коннект сокета
VI
ну я только по результату могу сказать – если напрямую мониторить процесс, то дубли есть (дубль – это на один канал два процесса когда создается, например по рефрешу F5 на клиенте, у которго отключены вебсокеты, и тогда будет две записи о дисконнекте), если слушать презенс – то дублей нет