Wait. Are you saying DOs will not be available in every colo even after GA?
Wait. 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?
CExactly.
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.
WIn the next 1-2 year 99% of our clients (for that particular solution) will be here... So yes...
WWe have other solutions that we plan to migrate to cloudflare workers + DO, and have more coverage worldwide, but we are using this first product to benchmark our needs before we start our main product migration.
WAlso, here in Brazil we have the LGPD, and similar to the EU GDPR, for some contracts we need to keep our data here to be compliance.
KOut of curiosity, if we supported "ephemeral objects" -- like durable objects, but with no persistent storage -- in all colos, would that solve your problem?
CThat would work, yes, since I would just need to delegate storage requests to another DO, but those wouldn't be in the critical latency path. Most convenient for that would be if I could create a new websocket connection from that ephemeral DO to the persistent DO.
WThe question is not for me, but that also can help our user case too, the majority of our DOs are storageless.
WOf course…
HI don't think so, as the main reason that Itty-Durable exists is to remove the need for performing fetch requests to your DO, which aren't necessary for KV anyway.
IIt's weird that sometimes is showing it's logs of the durable object, and sometimes it doesn't.
IAlso I am trying to have an in-memory list of connected users to a Durable Object. Basically doing
Iand as soon as a user connects I do
IBut when I have an query that tries to get those in memory users I get returned nothing, it stays empty
ADo the "automatically cached" -operations count as billable reads?
Ahttps://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/
That message was sent before this blog post was made - does it still apply?
That message was sent before this blog post was made - does it still apply?
ANevermind, these changes were made a couple of weeks before that blog post, so the answer is probably yes.
Jyea he had mentioned having the blog post written back when the change was deployed, but holding off on the blog post until after "impact week". Although pricing around DO is not completely nailed down yet, I'd be surprised if cached reads were not billed at the same rate. I guess we'll find out : )
AI'm just asking cause I need to decide whether to store the value as a variable or just read it each time
Jimo variables every time - but unfortunately it's still possible to store too much (even like 12mb) so that a bunch of these instantiated into the same isolate will collectively blow the per-isolate memory limit. But that will depend on how you are accessing, how many you have at once, etc
CEven more convenient night be an “ephemeral/durable hybrid” object that automatically delegates storage ops to elsewhere - trading storage latency for client latency if the colo doesn’t support DOs directly.
CWrangler only shows the log after a request has finished. For a websocket connection that can be a very long time.
CAm I interpreting this correctly that it is possible a worker and a DO may be loaded into the same isolate if they are the same script, sharing the same global scope?
Or put differently, every isolate loads the whole script, and then it may receive a worker fetch as well as a DO instantiation+fetch?
Or put differently, every isolate loads the whole script, and then it may receive a worker fetch as well as a DO instantiation+fetch?
WWe use KV with itty-durable because many of our data is bigger than DO value size and also the distributed side of the KV is also nice!
HSo you wrap KV in itty-durable?
WI just make my own midleware to handle the KV calls. Nothing fancy.
HSorry, I was misinterpreting "using KV with itty-durable" as "using itty-durable as an interface for KV". My mistake!