-
Notifications
You must be signed in to change notification settings - Fork 30
Reset UAID when too many messages are stored #473
Comments
@martinthomson thoughts? Other PS's do something similar allowing clients to recover and re-sync state in the event an app-server messes up. At the moment we have no limits, so if someone makes a thousand pop-ups..... heh. |
So you are talking about dropping the subscription when this happens, right? On reconnect, the client will then fail and that leads to a new subscription, which seems fine to me. |
Yes, it'll in effect drop all subscriptions (we have no efficient way to count messages per subscription, just over all stored). So the client can resubscribe then. |
#643 will alleviate this issue greatly as messages can be replaced instead of just expired. So I'm upping its priority and implementing it first. For this ticket, I believe the best path is:
This alleviates the delete 'write' overhead by letting table rotation delete all the stored messages. |
There's a limit on the number of channelIDs that we can store for a given UAID. We'll also need to communicate this to the client when we fail to assign a new channelID. (Otherwise we could go into a death spiral as a new UAID is assigned, and the client again tries to add too many active channels to the given UAID.) |
We currently have no limits on max messages. However, if a developer accidentally sends a huge amount, they'll end up hitting our quota and be silently unsubscribed. We should be more lenient in these cases and try to accomdate accidents by resetting the UAID on connect if there's too_many_stored_messages, so that the registration handlers registered may trigger.
The text was updated successfully, but these errors were encountered: