Playground site is not running (fix recurrent crash)
Closed this issue · 7 comments
More of a general issue than anything code-related, but the dream.as site does not appear to have a web server running (or accessible) currently. A check via shodan.io shows only port 22 (SSH).
I've since manually restarted the server several times. There is some bug that causes it to crash every now and then, which needs to be fixed. I am turning this issue into a reminder about that, as I would also like to stop checking it manually so often.
@aantron do you need any help with this? How deep is this bug? Is this playground open-sourced? Even with bug existing, we can solve manual restarting problem with typical devops practices :)
I could definitely use help with this due to time constraints! I realize your question was in August, but replying for the sake of clarity :)
The playground is open source here. It's running in a DO droplet. I could either give access to that droplet, or it could be run in another droplet. I doubt the bug is deep, but I just don't have time to track it down. I think I would prefer to find the bug rather than apply devops practices without debugging first, though, no doubt, devops improvements are needed regardless of any bugs :)
This appears to be an instancee of #230, so caused by an upstream problem in websocket/af. I don't want to debug it too much immediately, because the Eio version of websocket/af might not have this problem, and we are likely to port to it soon. The devops way might be the better way in the meantime.
In fact, it appears there is a new infinite loop in recent websocket/af, analogous to #230, but now in Websocketaf.Wsd.close. Still looking into it.
I've decided to take the playground down for now and not try to maintain it. It seems to be crippled by an upstream issue, but I'll be looking into potentially replacing the upstream Web stack anyway in the near future, so the specific current issue may not be worth fully diagnosing or fixing. I'll look into getting the playground running again after deciding on the Web stack.