1. 10 Aug, 2020 1 commit
  2. 30 Jul, 2020 3 commits
  3. 29 Jul, 2020 1 commit
  4. 28 Jul, 2020 2 commits
    • Richard van der Hoff's avatar
      1.18.0rc2 · 7000a215
      Richard van der Hoff authored
    • Erik Johnston's avatar
      Typing worker needs to handle stream update requests (#7967) · a8f7ed28
      Erik Johnston authored
      IIRC this doesn't break tests because its only hit on reconnection, or something.
      Basically, when a process needs to fetch missing updates for the `typing` stream it needs to query the writer instance via HTTP (as we don't write typing notifications to the DB), the problem was that the endpoint (`streams`) was only registered on master and specifically not on the typing writer worker. 
  5. 27 Jul, 2020 8 commits
  6. 24 Jul, 2020 6 commits
  7. 23 Jul, 2020 6 commits
    • Patrick Cloke's avatar
    • Patrick Cloke's avatar
    • Richard van der Hoff's avatar
      Put a cache on `/state_ids` (#7931) · 70788669
      Richard van der Hoff authored
      If we send out an event which refers to `prev_events` which other servers in
      the federation are missing, then (after a round or two of backfill attempts),
      they will end up asking us for `/state_ids` at a particular point in the DAG.
      As per https://github.com/matrix-org/synapse/issues/7893, this is quite
      expensive, and we tend to see lots of very similar requests around the same
      We can therefore handle this much more efficiently by using a cache, which (a)
      ensures that if we see the same request from multiple servers (or even the same
      server, multiple times), then they share the result, and (b) any other servers
      that miss the initial excitement can also benefit from the work.
      [It's interesting to note that `/state` has a cache for exactly this
      reason. `/state` is now essentially unused and replaced with `/state_ids`, but
      evidently when we replaced it we forgot to add a cache to the new endpoint.]
    • Richard van der Hoff's avatar
      Abort federation requests if the client disconnects early (#7930) · 4876af06
      Richard van der Hoff authored
      For inbound federation requests, if a given remote server makes too many
      requests at once, we start stacking them up rather than processing them
      However, that means that there is a fair chance that the requesting server will
      disconnect before we start processing the request. In that case, if it was a
      read-only request (ie, a GET request), there is absolutely no point in
      building a response (and some requests are quite expensive to handle).
      Even in the case of a POST request, one of two things will happen:
       * Most likely, the requesting server will retry the request and we'll get the
         information anyway.
       * Even if it doesn't, the requesting server has to assume that we didn't get
         the memo, and act accordingly.
      In short, we're better off aborting the request at this point rather than
      ploughing on with what might be a quite expensive request.
    • Michael Kaye's avatar
    • Patrick Cloke's avatar
  8. 22 Jul, 2020 6 commits
  9. 21 Jul, 2020 6 commits
  10. 20 Jul, 2020 1 commit