HSorry, meant the other way around.
IDo console logs show up in 
wranger tail
EDOs 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.
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.
ENo, they do not unfortunately..
IIs websocket to websocket communication possible from Durable Workers to Workers?
HWill DO's be able to migrate themselves at some point?
EThat is certainly part of the vision for DOs, but that won't be part of the first release I would imagine..
HProbably a bit of finagling to get it GDPR-Compliant...
II'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
EIt is already possible to restrict DOs only to EU colos.. https://developers.cloudflare.com/workers/runtime-apis/durable-objects#restricting-objects-to-a-jurisdiction
It isn't possible to automatically migrate a DO after it is created, especially if it has stored data already.
It isn't possible to automatically migrate a DO after it is created, especially if it has stored data already.
EI don't have a lot of experience with the websocket side of things @itswendell, but I feel it should absolutely be possible?
HOn the finagling, I meant getting the auto-migration to be GDPR-Compliant.
EOh no.. that is the easy part for a change 
.. the technical challenges are way harder tbh..
.. the technical challenges are way harder tbh..HMy brain hurts just thinking about it.
ESo does mine, so I am glad we have an amazing team working on that tbh.. 
HSo 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?
II'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.
EThat is correct. (Assuming it saved something to storage). If it didn’t save something to storage I believe it could.
IActually, I think I just made it work 
IIs there are a package / endpoint to make the
colo
JI believe they are standard IATA airport codes (https://en.wikipedia.org/wiki/IATA_airport_code) but that list posted yesterday (https://speed.cloudflare.com/locations) would be a nice cf-specific endpoint to use, for as long as it's around
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 ...
IThanks that helps, I think I'll try a simple free API reverse geocoding API for now, see how that works.
WAny 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.
EYou 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?
EI 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 
IIs 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).
IDo DOs auto migrate to a location once certain users from a specific location start using it more?
IThis was something that is planned for later right?
WThey 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.
WThey 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.
WI can live with aditional latency in while our app is in beta. But I was (maybe naively expecting) to got anything close before the end of the year.
CMake 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.
KIs there a way to get rid of the cold starts on the durable objects? When there is no request for a while it takes longer time.
CWait. Are you saying DOs will not be available in every colo even after GA?
CI’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.
M
COkay 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?