How'd I not noticed that? I needed the locations of the datacenters for a project, so I scraped them
How'd I not noticed that? I needed the locations of the datacenters for a project, so I scraped them off the statuspage then geocoded them.
CGuess I should update my latency map durable-objects
Ji did the same until i found that endpoint!
Jgood thing workers makes scraping so easy…
CActually no - the coords in that list are literally the airport coords which makes the map look rather weird zoomed in. I'll keep my reverse geocoder.
HDoes your Latency Map test latency to your datacenters, or the actual Colos?
Cit's measuring roundtrip latency client – worker – DO – worker – client using a websocket connection (as we do for our "real" apps)
HAnd how do you figure out which colo the DO is in?
HShould have foreseen that.
C
CHmm, curious. One of my DOs moved from LAX to SJC today 
Is that supposed to happen?
Is that supposed to happen?HMight have been me...
HSorry about that, @codefrau!
CHuh? How? Supposedly DOs are fixed to one colo, unless that colo is down, I thought
HI believe that DOs persist in one colo, until they are shut down. Once they are triggered again, they are reinitialized in the nearest DO-ready colo to the incoming request.
CThe way @kentonv_cf described it is that it lives in one colo, but is replicated to a few near colos for backup. It would not "jump" from the EU to the US.
HAccording to your log above, it seems that because there was an extended period of time with no requests, it was terminated(FRA). Once someone else triggered it(Me, probably), it was reestablished in the nearest Colo(SJC) to my request.
HAt least I believe so, I'm having a hard time figuring out that log.
CLAX being down for a while would make sense, but I'd have assumed it would move back to LAX once its up again.
HNot if the next request comes from somewhere else, before it can reestablish itself there.
Cthere were like 13 hours in between
HThe change?
Cto "jump back" from SJC to LAX
C... but maybe SJC is now the "authoritative copy"
HHow many times was it triggered in those 13 hours?
CNever. This is the complete log.
CI left out some detail but the last connection in SJC closed at 2021-08-05 03:22:52.283 PDT
HSo, somewhere within those 13 hours, the SJC Instance was terminated. Then, after 13 hours had passed, someone sent a request, initializing a new instance at LAX
HNot me then.
Cno it's in SJC now
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 