vdbergh

> set 30 connections in nginx and 10 connections in waitress (like the 10 threads). IMO the web works with queue to deal with spikes, and we don't want the...

Of course I may be wrong but it seems natural to me that if Fishtest can handle say 7 request task calls per second it should be given the opportunity...

> File "rundb.py", line 86, in set_inactive_task with self.active_run_lock(str(run_id)): `set_inactive_task` does not grab itself any new locks after acquiring `self.active_run_lock(str(run_id))` which is a reentrant lock. Is it theoretically possible for...

Ok `update_task()` grabs `self.run_cache_lock` (via `buffer()`) while still holding `self.active_run_lock(str(run_id))` Not sure if this a smoking gun but it would probably be safer to first release `self.active_run_lock(str(run_id))` before acquiring a...

Ok I think I understand. When `update_task()` invokes `buffer()` the latter acquires `self.run_cache_lock` which may be held by `flush_buffers()` which may itself be waiting for `set_inactive_task()` via `scavenge()`. This completes...

This bug was my fault (introduced in #2020)... Sorry about that. I guess it would be useful to do an audit of all locks being used in Fishtest and the...

Tonight I will make a PR with a fix.

> Current RunDb lock acquire/release graph Which tool did you use for this?

I made a PR which presumably will fix this issue. See #2042 . However the semantics of the various locks used in Fishtest should be clarified.

This should happen in the beginning of the test when there are very few games and the approximations used are not valid. I agree it is not nice. I will...