Is there are a package / endpoint to make the `colo` field more human readable?
Is 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?
M@kentonv_cf 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?
KTBH @brett_h knows the internals better than I do, but IIRC this is a known issue right now where after a failover to a different colo, we don't proactively migrate the object back.
EThat is my understanding.. there will probably be a much better coverage world-wide, but probably not every single colo. But I am not the definitive source on this
CDoes that apply to DOs with unique IDs too? Or just named DOs?
CRight that’s what I saw.
WSo, can i hope that get at least one here on Brazil (or close)?
CFor us round trip latency to the DO is what matters. If there was none in South America or Australia for example we’d have to keep our own servers running there which makes our session management much more complex than switching over to cloudflare completely.
WYes, that what i was thinking... today only São Paulo get my regular worker traffic, and our DO are all to New Jersey. We will release our solution this month and keep in closed beta until end of the year, but after that all those incremental delays will be vary bad for our solution, sometimes we need to wait 2-3 seconds to update one document because several round trips.