DOs that do not have any external state (used the storage API) can be garbage collected and restarted at some other point.
But if I am not mistaken we did have an issue in LAX recently, so it may have been a fail-over indeed. And SJC being the copy with the data now. And you are correct in that a DO will not leave the cluster it is currently part of, so it won't move from the US to the EU etc.
I've tried this in multiple ways now but can't get it to work. In short, I have a worker which manages incoming websocket connections for GraphQL subscriptions. Once a subscription comes in for a specific chatroom, a connection needs to be opened (or forwarded) to that durable object of that specific chatroom.
The fetch method of stubs don't seem to return a webSocket, created and passed down as response on the durable object.
I can't seem to pass a websocket to the durable object
So when you say it can't auto-migrate, does that mean that if a DO is initialize spawned in the US, but later terminated(Not Wiped), it can never be recreated in Europe?
I'm not so sure about that, I think the tricky thing is is that the connection comes starts in the Worker. The Worker creates and start's listening to WebSocket events with the client. Once a websocket event comes in that subscribes to a specific chatroom channel, I need to somehow communicate from the Worker to the Durable Object in real-time.
I can't start a client / server from the Worker since there is no way I can pass the client in a Fetch request to the Durable Object.
I can't start a client / server from the Durable Object, since the response of the durable object with fetch, doesn't include the webSocket.
An IATA airport code, also known as an IATA location identifier, IATA station code, or simply a location identifier, is a three-letter geocode designating many airports and metropolitan areas around the world, defined by the International Air Transport Association (IATA). The characters prominently displayed on baggage tags attached at airport ...
Any plan to activate any DO here on SouthAmerica? It’s bad to always be routes to US … that ads to much latency that makes hard to test our software for any regression.
You get a specific bank of CPU time after every message. So I think if you don't send any messages, it will run out and terminate the DO at some point?
I am sure we would love to activate DOs in more regions world-wide, but the requirements are to have multiple high quality dcs close together with multiple reliable network connections. And those are hard to find in areas like South America. I know exactly how you feel in Australia
Is there a list of locations for DOs? Whenever I create one in amsterdam it seems to be spawning in France. (according to reverse geocoding the IP of the DO).
They open 25 new locations here on Brazil. But 100% of our workers traffic is only on one colo (GRU)…. I always assumed that we will get at last one DO location here. Because of not, it’s better to stick with something on google, aws or azure that’s full range products here.
They open 25 new locations here on Brazil. But 100% of our workers traffic is only on one colo (GRU)…. I always assumed that we will get at last one DO location here. Because of not, it’s better to stick with something on google, aws or azure that’s full range products here.
Make the chat room id part of the web socket request url to the worker. Then pass that same request to the DO stub’s fetch(). That way the web socket connection gets forwarded to the DO.
I’d have expected that DO to jump back to LAX, where it was originally. But it seems to now prefer to live in SJC. Is that to be expected for “named” DOs? That would make some sense since the DO’s location is cached in other colos.
Okay makes sense. What about DOs with unique IDs though? Their location doesn’t have to be cached, that was part of the design. Is that still true? Meaning even if that DO was temporarily resumed on another colo, would it “snap back” to the colo encoded one that is operational again?