mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
22a1b296e3
I'd be pretty surprised if these were happening but meh, a computer running at capacity can make the runtime scheduler do all kinds of weird shit, so this locks down the behavior around slot launching. I didn't load test much as there are cries of 'wolf' running amok, and it's late, so this could be off a little -- but I think it's about this easy. cold is the only one launching slots for itself, so it should always receive its own slot (provided within time bounds). for hot we just need a way to tell the ram token allocator that we aren't there anymore, so that somebody can close the token (important). If the bug still persists then it seems likely that there is another bug around timing I'm not aware of (possible, but unlikely) or the more likely case that it's actually taking up to the timeout to launch a container / find a ram slot / find a free container. Otherwise, it's not related to the agent and the http server timeouts may need fiddling with (read / write timeout), if ruby client is failing to connect though I'm guessing that it's just that nobody is reading the body (i.e. no function runs) and the error handling isn't very well done, as we are replying with 504 if we hit a timeout (but if nobody is listening, they won't get it).