we send presence updates to all the servers that our users share rooms with, whenever a remote user joins any of those rooms #3962
Comments
neilisfragile
added
z-p2
|
This should be a high priority "p1" or whatever issue. The presence spam is a rather large Here's an example just looking at Construct's console just this moment: And there are a plethora of others which are immediately discarded as redundant or stale and don't even show up. |
neilisfragile
added this to Holding pen
in Superceded by https://github.com/orgs/matrix-org/projects/8
via automation
|
this needs fixing pre-v1.0. |
neilisfragile
removed this from Holding pen
in Superceded by https://github.com/orgs/matrix-org/projects/8
|
Anecdotally, I'm now seeing outgoing federation transactions at the rate of about 70Hz (almost entirely made up of EDUs) which is causing my server to fall behind sending PDUs, which in turn makes conversations quite difficult to have. If we can't fix the spam, could the federation sender at least prioritise PDUs over EDUs? |
|
sure, feel free to write a PR. frankly it should be easier to fix the bug. |
Primarily this fixes a bug in the handling of remote users joining a room where the server sent out the presence for all local users in the room to all servers in the room. We also change to using the state delta stream, rather than the distributor, as it will make it easier to split processing out of the master process (as well as being more flexible). Finally, when sending presence states to newly joined servers we filter out old presence states to reduce the number sent. Initially we filter out states that are offline and have a last active more than a week ago, though this can be changed down the line. Fixes #3962
Primarily this fixes a bug in the handling of remote users joining a room where the server sent out the presence for all local users in the room to all servers in the room. We also change to using the state delta stream, rather than the distributor, as it will make it easier to split processing out of the master process (as well as being more flexible). Finally, when sending presence states to newly joined servers we filter out old presence states to reduce the number sent. Initially we filter out states that are offline and have a last active more than a week ago, though this can be changed down the line. Fixes #3962
|
Hopefully fixed by #4942 |
I suspect this is the root cause of #2514 and a bunch of other similar reports like #1429 and #3490.
Whenever a remote user joins a room, we look for any local users that are in that room, and then, for each local user, send out presence updates to all the servers that user shares a room with.
The text was updated successfully, but these errors were encountered: