Weird lockup/fault happening on heavy concurrent use (proven by ab -n 2)
yrashk opened this issue · comments
Different theories tried throughout this day:
- missed ticks
- cond_broadcast lockup
- massive reticks
Still confused about what's happening with it.
Thoughts: it might (theoretically) happen if there is a bug in tick flushing and we flush before the thread is ready to process it. Unlikely, though. Flushing algorithm is quite trivial.
Observation: most (if not all) ticks that got no response are result ticks. Which kind of makes sense. We shouldn't store them in state.ticked, they aren't going to be removed ever.
This might be related: beamjs/beamjs@0155c2f was introducing an interesting behaviour: only every second request was getting through.
Finally got a test case reproducing this. Hopefully will be able to fix it soon! Apparently calling for JS functions in parallel doesn't cause the system to lock up in any way, while doing the same for Erlang functions definitely does so. So most likely the problem is not in CallTickHandler but WrapFun.
5cd1603 seem to fix the test
Judging by doc_browser, it works much much better now, although I have seen one lockup so far. So, not completely eliminated yet, but works SO much better now
Works quite well so far. Closing this case. Hopefully it will not resurrect.