django channels group subscriptions

[Brian May]

Hello,

I would like to be able to create a Django Channels group such that:

1. Websockets can can subscribe and unsubscribe (or disappear) to group that the client specifies.
   
2. When the first client subscribes to a group, it starts some process (e.g. via celery task) that feeds this group with real time notifications about a particular event.
3. When the last client unsubscribes (or expires) from the group, it kills the process or marks the process to self-destruct when next convenient.

Step 1 is reasonable with this is groups. However not sure about 2 or 3. I can't see anyway with the existing groups to find out when the first client subscribes or the last client disappears.

I could replace/override ChannelLayer with my own code, but this seems unnecessarily intrusive. I could also write my own groups code, this also seems maybe excessive.

Any ideas or recommendations?

Regards

[Andrew Godwin]

You can't do what you ask with the current Groups system - it is deliberately very simple as anything more complex involves picking scaling tradeoffs that are particular to the thing it's powering. You'll have to layer some of your own code on top of groups (you can keep groups for the broadcast message bit, and then add state management for processes done in the websocket connect/disconnect methods)

Andrew

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20af7f07-3cbe-46a0-a968-e1562f1340ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian May]

On Friday, 2 June 2017 13:04:48 UTC+10, Andrew Godwin wrote:

You can't do what you ask with the current Groups system - it is deliberately very simple as anything more complex involves picking scaling tradeoffs that are particular to the thing it's powering. You'll have to layer some of your own code on top of groups (you can keep groups for the broadcast message bit, and then add state management for processes done in the websocket connect/disconnect methods)

I guess this means I need to do my own expiration processing too.

Are there any examples you know of that I can look at for inspiration?

I am surprised this sort of thing doesn't seem to have come up before.

Thanks 

[Andrew Godwin]

I don't have any direct examples to hand - and this sort of thing does come all the time, but much like Django is not in the business of including a full CMS, Channels can't add lots of high-level features without really narrowing the usage - it's a general framework for you to build something on.

Andrew

--

You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1d699f5b-441b-455b-9828-2a18326b616f%40googlegroups.com.

[Brian May]

On Friday, 2 June 2017 14:08:40 UTC+10, Andrew Godwin wrote:

I don't have any direct examples to hand - and this sort of thing does come all the time, but much like Django is not in the business of including a full CMS, Channels can't add lots of high-level features without really narrowing the usage - it's a general framework for you to build something on.

I am not sure I can how how to do this expiration myself.

inmemory.ChannelLayer has a _clean_expired() method that looks like it will look for all outgoing messages that haven't been sent before expiring. However it looks like my application, being a layer on top of groups doesn't have access to any of this information.

So maybe I need to put some sort of keep alive mechanism in place, and completely ignore this existing expiration mechanism?

Thanks

[Andrew Godwin]

You should only use the documented, public groups API - anything else will vary based on the backend you use. You will, indeed, need your own expiration logic and backend for this process stuff - an easy entry point would be one of:

- A database row per process with a timestamp bumped using keepalive-style calls

- A redis key per process with an expiry bumped using keepalive-style calls

This will probably be the most reliable thing as keepalive means that even if you miss a disconnect event, it'll shut down eventually (the tradeoff being that you might miss several keepalives and then shut it down early)

Andrew

--

You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3e22d613-29a3-4dc0-b99d-63db8616f7de%40googlegroups.com.