and KIX

there was a latency spike in apac about 15:45 utc, have you seen any issues since then?

lookups are not proactively replicated, they're cached on request. I understand the general desire to have an interface for getting a DO only if it already exists, but in this case, unless you have enough info on the request itself to determine whether it's GDPR, you'd have to do lookups of both regardless. At that point the only difference is the creation of an otherwise empty record.

yep 9.45 in gmt-6, found between 9.30 and 10.00 which seemed like kind of a long time, back to normal now!

Is there any plan to allow expiry of keys from the DO storage, like KV allows? (I assume that the DO storage is pretty much a KV equivalent...)

That's perfect! Thanks!

I'm having a little problems trying to get up and running with Durable Objects. I'm trying to work through some of the example in the documentation but I can't seem to make anything work. I'm sure I'm just missing something. What I have is a post coming from itty-router and would like to save that data into Durable Objects. I have tried adding the binding into the wrangler.toml but allows get errors when I do wrangler2 dev. I was hoping there maybe some better example of how to get going with this product.

have you tried one of the templates linked in https://developers.cloudflare.com/workers/learning/using-durable-objects/#uploading-a-durable-object-worker

@kenton , one more question, does the input gate remain closed even if you have an await? For instance, I have this function

async hydrate() {
  if (this.hydrated) return
  this.value = await this.state.storage.get('value')
  this.hydrated = true
}

If I call that at the beginning of my fetch handler with:

await hydrate()

Does that potentially let another request get started in the case when this.hydrated is true?

since

hydrate()

itself only waits on storage operations, awaiting

hydrate()

will not open the input gate.

That makes me think some other await might. If so, what's an example of that? I'm pretty sure, I remember you writing that an external fetch() is like a special event so it also won't open the input gate, but am I mis-remembering that?

Thank you for all your messages. To answer to your question, on our UX screen for signup, we have a sentence like « I live in [ France ] » where France is pre-selected bases on request.cf.country code. And based on the list of EU countries we known if we need to create the DO in EU jurisdiction. Finally now, we uses a central DO lookup in Europe to known if a DO is already associated to an email. We could also do that with KV, but as our KV keys will be always cold, CF edge KV will always call one of the main KV datacenter, so it's not very fast and we also need to hash the email address if stored in KV. So, our worker at edge can ask the central DO what is the DO ID of this associated email, and known if exists without to start up it.

I think the intention was also that you would be able to tell whether a DO exists without first incurring a fetch call…

indeed, and with my new setup ( worker => DO central ) to known if an DO associated to an email exists, I still need 1 connection/start of the DO central, but this prevent to start 2 DO (worldwide + eu jurisdiction) with a slow idFromName(email). With a central DO, I can also use the faster newUniqueId(), and also don't need to save/request an hashed email address (as the central DO is in EU jurisdiction)

I have a question how the memory is managed for DO: « If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine and share the 128 MB of memory. » If we have 2 DO instances of the same class that running on the same colo, and share the same 128MB of memory. Imagine one currently uses 100MB and the other 27MB, then the second increase his memory usage and so we reach memory limit of the 128MB shared memory. What's happening? Is this second instance is killed and recreate automatically in exactly the same state on another 128MB VM of the colo ?

They'll both reset their in-memory state, and if you keep using memory the same way, that will keep happening. There's work on the roadmap soon to make this roughly equivalent to a stateless worker in terms of how many isolates can run on the same machine, but that's the current state of things

regarding "with a central do", at that point you're limited to the throughput of a single DO. Maybe that's fine if you're only using it for logins, but keep that in mind

How do you expect to get information without asking for it? It's not proactively replicated to every colo.

Any plan to support 1-isolate-per request setups? As in, for regular Workers, a single isolate will never process two Requests at once? And for a DO, by default just only processing one Request at a time?

regular workers don't work that way

you can definitely exceed memory in a regular worker due to multiple concurrent requests

not parallel, but concurrent

I mean, the database lookup is currently done on

fetch

right? So would it be possible to do said lookup, without the accompanying fetch that actually creates the object if it doesn’t exist?

Yeah, I was asking more about the future, rather than how it works right now

my point is literally the only difference is creation of an empty record, which only matters to you if the location is wrong, which in this case I do not see how it is

doing 2 concurrent fetches is going to be only as slow as the fetch that returns you the one that "exists"

I was also asking in the sense of, for example, establishing whether a User exists. I could fetch it, but if the DO is far away from where I’m currently at, that will might be slower than hitting core/cache if it is available.

A user, in this case, being stored solely in a single DO

It's really annoying currently, I hope this task on this roadmap could be done soon, because this mean currently we can break everything because the 2 instances can't restart... ( and we still pay for 2x 128MB GB-s, even if it's sharing the the same 128MB and in theses scenario can't works anymore)

You're not wrong, plenty of us are concerned about this