How to architect a Group in Django Channels so that the 24 hour group_expiry time does not harm my communication?

Viewed 676

In my infrastructure, I have a fleet of RPi devices that connect in to our webserver over a websocket. The websocket connection ideally remains open permanently and acts as the conduit where the server can push information down to the RPi device, and the RPi can send information back to the server.

When the RPi device connects in to Channels, it joins a specific group based on the configuration in the connection payload. The server doesn't need to know what devices are connected because it uses the same heuristic to algorithmically determine the group name to send out information to appropriate devices, if they'd exist.

The place I'm getting destroyed is the group_expiry time in channels is set to 24 hours. Additionally, the websocket timeout is also set to 24 hours. I can deal with the websocket timeout because the JavaScript code will automatically attempt a reconnection as necessary. However, when the group expires after 24 hours, my devices stop receiving the communication over the group.

The net effect is that every 24 hours, I have to bounce Daphne in order to have all of the groups reset and recreated. Exactly 24 hours later, Channels purges the groups and everything comes to a standstill again.

I've looked at this issue thread: https://github.com/django/channels/issues/999. I've considered adjusting the timeouts much higher, but I don't know if that would have any adverse implications to any other parts of the infrastructure. Groups will always be controlled and so I don't believe I really benefit at all from the housekeeping that the group_expiry does for me.

Are there any adverse implications of finding a way to disable the group expiry? Is there a different architectural approach I should be leveraging, for instance, wire up the date into the group name and automatically create groups and membership with the current date so that the groups can expire without bringing the communication down? (that contrived example was admittedly silly). I guess I'm looking for architectural advice.

Perhaps I'm even going down the wrong road entirely. I guess I should first prove that it really is the group expiry timeout that is killing me by figuring out how to change it to something like 2 hours and see if the site goes out.

Here's the package where the group_expiry setting is discussed: https://github.com/django/channels_redis

0 Answers
Related