Size: a a a

2019 September 02

ŹR

Źmićer Rubinštejn in pro.elixir
Victor Ivanov
ну я только по результату могу сказать – если напрямую мониторить процесс, то дубли есть (дубль – это на один канал два процесса когда создается, например по рефрешу F5 на клиенте, у которго отключены вебсокеты, и тогда будет две записи о дисконнекте), если слушать презенс – то дублей нет
Ну presence просто обеспечивает уникальность ацдишника
источник

VI

Victor Ivanov in pro.elixir
айдишника чего?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Воот, это самый интересный вопрос)
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Когда я смотрю в этот пример
https://hexdocs.pm/phoenix/Phoenix.Presence.html#module-example-usage

Я вижу

Presence.track(socket, socket.assigns.user_id


Или по русски юзер_айди
источник

ŹR

Źmićer Rubinštejn in pro.elixir
А как делаешь ты - я не знаю
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Но без id presence не работает
источник

VI

Victor Ivanov in pro.elixir
{:ok, _} =
 Presence.track(socket, subscription_id, %{
   subs_id: subscription_id,
   online_at: inspect(System.system_time(:second))
 })
источник

VI

Victor Ivanov in pro.elixir
точно так же, по сути
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Вот именно. У тебя есть subscription_id, по которому ты пишешь
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Так как может быть дубль то, если процесс с этим id ты уже мониторишь?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Ну вернее это надо реализовать
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Но тогда не будет никаких узких мест
источник

ŹR

Źmićer Rubinštejn in pro.elixir
И все будет асинхронно
источник

VI

Victor Ivanov in pro.elixir
я просто заюзал вот этот код http://derkobe.github.io/2016/01/11/get-notified-when-an-user-leaves-a-phoenix-channel.html изначально, и как сам видишь, он не смотрит не на какие параметры, просто трекает процесс

счетчик я уже ревлизовал для варианта с презенс, потому что там надо отписываться от топика, который слушаешь все равно
источник

VI

Victor Ivanov in pro.elixir
но без внешнего процесса все равно не обойтись, иначе как трекать, когда процесс канала умирает? Он же сам не сможет такое трекнуть
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Victor Ivanov
но без внешнего процесса все равно не обойтись, иначе как трекать, когда процесс канала умирает? Он же сам не сможет такое трекнуть
Не может
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Отключение трекать нужно другой процесс
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Тогда наверное нужен presence
источник

VI

Victor Ivanov in pro.elixir
Ну вот Крис сам такое советовал:

It’s not entirely clear what your use case is, but you have a couple options:
1 On join, have another process monitor you, then when you disconnect, they will receive {:DOWN, ...} and you can handle whatever you need to do. This only works assuming you need to react to clients leaving the same way, regardless of how many are connected. For example, if I open 5 tabs, this setup will fire the callbacks as I close each one, rather than when my “last” tab is closed. This may or may not be what you’re wanting.
2 You can have another process call MyApp.Endpoint.subscribe("some:topic") where the topic is the channel topic(s) you’re wanting to watch over. This process will then receive presence_diff events and you can react accordingly. This setup let’s you know more, like how many tabs/devices are connected for the same user, and whether the “last” one has left, but then you also need to manage when to subscribe to new topics, and unsubscribe from ones that are no longer being tracked by active channels on the local node.
источник

VI

Victor Ivanov in pro.elixir
источник