Thanks that helps, I think I'll try a simple free API reverse geocoding API for now, see how that works.

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.

i left a browsertab open for a day and i see this

seems every ws connection lives around 1.7hrs

but sometimes it gets to 4.4hr+

any idea what could be exhibiting this behavior?

why does it not stay 24/7

it seems the "stat" endpoint lives around 4.4 hrs the "user" endpoint 1.7

the stat endpoint is lighter in processing

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).

This can happen when the original colo is having a problem and you send a request during it -- we'll fail over the DO to another colo

Do DOs auto migrate to a location once certain users from a specific location start using it more?

Other than failover situations like mentioned above, DOs don't migrate between locations after creation today.

This was something that is planned for later right?

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.

I 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.

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.

yeah, it's in our future plans

Is 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.

Wait. Are you saying DOs will not be available in every colo even after GA?

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.

https://discord.com/channels/595317990191398933/773219443911819284/872199430265253969 (from the source of truth)

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?

@kenton is best positioned to chime in when he’s back, but I assume you’re seeing it stay in SJC after maintenance moved it from LAX?