This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Incoming federation transactions stack up indefinitely #9489
Labels
T-Enhancement
New features, changes in functionality, improvements in performance, or user-facing enhancements.
Since #8342, we apply the federation ratelimiter after the transaction linearizer. The net effect is that, if we cannot keep up with incoming transactions, we allow them to stack up indefinitely (there can only be one thread inside the transaction linearizer, so we never hit the concurrency limit on the ratelimiter). This can use a lot of memory, and it's not the way matrix federation transactions are meant to work (if the remote gets behind, it should drop messages until it catches up).
It feels like the ratelimter is pretty redundant there. (Admittedly it still has some use as a true rate limiter rather than a concurrency limiter, but that's a bit of an edge-case.)
Should we instead be using a separate ratelimiter dedicated to incoming transactions?
The text was updated successfully, but these errors were encountered: