Limit concurrent event sends for a room

[erikjohnston]

No description provided.

[richvdh]

So some explanation of what's going on here would have been helpful, but I think I've figured it out: the idea appears to be to pull the limiter up from create_event into create_and_send_nonmember_event, so that it covers send_nonmember_event as well as create_event (and thus limits the number of events in flight between the event_creator worker and master)?

so, sounds reasonable to me. A comment in create_and_send_nonmember_event as to why the limit is where it is would be useful.

I note that create_event is also called from RoomMemberHandler._local_membership_update and hence (if you keep chasing it back) from RoomMemberHandler.update_membership. However this is already limited to one-member-per-room via the member_linearizer, so there is no concern about the limit being removed on that path?

[erikjohnston]

I note that create_event is also called from RoomMemberHandler._local_membership_update and hence (if you keep chasing it back) from RoomMemberHandler.update_membership. However this is already limited to one-member-per-room via the member_linearizer, so there is no concern about the limit being removed on that path?

So ideally we'd probably want everything to be incorporated into the limit, but you're right in that I'm not hugely concerned that we don't catch membership events. Its also worth noting that limiting _create_event wasn't particularly useful other than to limit number of concurrent state resolutions.

[richvdh]

lgtm