https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • v
    yea my workaround was if it times out/dies the next worker to send a message on the websocket starts the timer again
  • v
    not super clean but seems to keep it ticking
  • d
    I'm not sure about how it's counted for setInterval - that seems a better match for a game loop tick anyway...
  • v
    thanks for the good news will look out for that
  • v
    i was thinking to use the CRON scheduler but 1minute resolution are too long for me. if CRON scheulder supported second resultion
  • d
    Well, you do want to have the ability to resume anyway - the worker will die at some point for whatever reason. You may as well just ignore it for now and the 10k limit will hopefully be fixed soon™️
  • v
    yes, so the important stuff gets stored to the persistent store inside the DO, the timer is just to check things like zombie sockets and to send pings down
  • v
    Copy code
    javascript
onmsg(sess, PONG) {
  now = Date.now();
  sess.next_disconnect = now + DISCONNECT_INTERVAL
}

tick() {
  now = Date.now();
  ping = JSON.stringify({op: "ping"})
  this.sessions.each(sess=> {
    if (now >= sess.next_keepalive) {
       sess.next_keepalive = now + PING_INTERVAL
       sess.websocket.send(ping)
    }
    if (now >= sess.next_disconnect)
       sess.websocket.close()
  })
  setTImeout(6000, tick)
}
  • d
    I'm not sure if you can reconnect without restarting the websocket, but my version just restarts the websocket so the zombie check isn't relevant anyway
  • v
    what do you mean restarting?
  • d
    I mean the client being disconnected and opening a new websocket
  • d
    I don't know your setup, but I am doing ping/pong from both ends and my client reconnects if the conn drops
  • v
    yes but the DO backend might think the client is alive
  • v
    and when client reconnects there will be 2 connections 1 is dead (but not disconnected)
  • d
    not if the DO has died! There will be zero connections until your clients start to reconnect
  • v
    but the DO has always >1 connections
  • v
    atleast for me
  • g
    unless the DO dies though
  • g
    if your client reconnects on conn drop
  • g
    that will re-initialize the DO into memory
  • v
    i think we are talking about different things. if the DO dies all the connects connected to it die, and when the next connection comes (i assume all connections are WS) itl spin up.
  • v
    but if there is say 100 connections and 1 of them goes zombied, there are 100 connections, websocket.send() will not fail to that 1 zombied but the client will not recv the message.
  • v
    if the DO dies in this case (due to maintenence/cloudflare server restart/other reason) then all of these 100 will disconnect yes.
  • d
    Yes, I was just responding about what to persist - my point was only that you don't need to persist the session stuff. So, what you're doing sounds fine. Your zombie checks will work while to DO does, if you hit the 10k limit you'll need a new DO anyway.
  • v
    Unfortunately hitting the 10k limit does not cause the DO to die. At least the last time I checked (a few weeks ago) it didn't. Meaning new clients will still connect but if the app relies on timeouts it will just not work properly.
  • d
    I haven't actually seen the error myself - this is an exception emitted by setTimeout?
  • v
    yes
  • d
    So given that you can't force a DO to terminate, what are you doing in your code? Besides migrating to a new DO I don't see a workaround
  • v
    we're delaying to use this in production until it's fixed
  • v
    If it at least died properly I'd be much happier.
1...110111112...567Latest