But again, if you want to use workerworker communication when you own both workers, I heavily recommend service bindings

Service bindings in its current form dont work well for us, since the bound workers share the same thread and POP. It looks like more advanced bindings are coming soon (Smart Placement etc) and hopefully that'll work for us

Great, let me check calling the second worker through its custom domain.

OMG I had no idea about this 🤦‍♂️🤦‍♂️🤦‍♂️ Thanks for pointing me to this!

Make sure you're not using Routes for this to work though, only Custom Domains.

Yeah, that's totally fine. We're already fully on custom domains

so the DFW network fail this morning https://www.cloudflarestatus.com/incidents/577d7nnvv1m3 is marked as resolved, but I've been seeing DO alarm failures (logpush entries with nothing in them) ever since (since around 9/10am this morning) - is this something that is still being monitored?

@john.spurlock Can you DM me a DO ID, and I can take a look?

Is there a CPU limit for tasks triggered by a durable object alarm. The docs make it seem like there isn't. Is this the case?

It should be 30s cpu time. Theres 30s cpu time per request: And an alarm just counts as a request

Actually I couldn't get this to work. I added a custom domain trigger to the second worker. The response from the second worker is 522 Timeout when the custom domain is in the same zone. If I move the custom domain trigger under another domain name, it works just fine.

(The entry point to the request is also a custom domain if that matters)

Is the worker <> worker communication over custom domain trigger (same zone) functional at the moment?

I recently read about **Building Waiting Room on Workers and Durable Object**: https://blog.cloudflare.com/building-waiting-room-on-workers-and-durable-objects/ There it's mentioned that you used one Durable Object per data center for sharding in order to aggregate data that then talks to a global Durable Object. Is it possible for me to create a DOs per data center for sharding as well? I assume that would either be done with any sort of identifier for the data center the code is running in. Alternatively creating a reference with Cache API somehow, since that is specific to the Data Center.

I don't know, can see if I can find out

Should be - https://discord.com/channels/595317990191398933/779390076219686943/974312830700515338

You can't create a DO in each data center, but you can create a DO per data center by using the name of the colo from the incoming request object in the name of the DO https://developers.cloudflare.com/workers/runtime-apis/request/#incomingrequestcfproperties

The documentation says that

colo

is

the three-letter IATA airport code of the data center that the request hit

Why would every data center correspond to an Airport? I don't really need to know if

colo

is unique per data center, but it struck me as very odd.

Physical locations aren't disclosed so the identifier is the nearest airport

The PoP, i.e LHR, could be multiple colos - i.e

lhr01

|

lhr08

|

lhr09

|

lhr10

|

lhr11

|

lhr12

https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/ touches on how some PoPs are multi-colo PoPs, but generally you never need to care about the colos.

Thanks @kian 👌

Just saw this, thank you so much!

Speaking of waiting rooms and how they work... if anyone ever does create an Edge based ingest that writes to a central DO so that we can have unlimited* writes per second to a DO should throw that in #783765338692386886 i'm sure a lot of people would like that who are too lazy to do it (me, that is me)

assuming you make it open source that is

Is there any way to run a large # of inserts into a durable objects storage? I want to load a few million entries. Seems like I can insert about 1k items / second (loading from r2). I would like for these loads to be done in a few minutes rather 15m / million. I'm using the batch put api with 128 values with allowConcurrency, allowUnconfirmed and noCache. Is there anything faster?

That's it, really, there's no side-door. Are you loading all of this into a single object? You could shard among more objects, depending on the use-case.

sharding among many objects is a non-starter for this workload. It is write intensive, but only once at object initialization. After initialization write throughput is capped at a few updates / s and most of the workload shifts to reads. Really need transactional consistency for writes across the entire key space to ensure correctness here. might need to take this back to the drawing board 🤔 🤔 🤔

> and most of the workload shifts to reads But how heavy is this workload? A single object is a single threaded (JS, of course) server

I'm probably over thinking this but I intentionally hold all my storage.put operations to after all await storage.get operations so I can think of all of those put operations as a single transaction, however, I have some DOs that keep some state in memory. If those put operations actually fail, my in-memory state will be out of sync with the storage state. I am thinking of refactoring so I never rely upon in-memory state but before I do that, I want to confirm that my worry is founded and that there isn't some easier workaround to never relying upon in-memory state? For instance, if there was a way assure that a DO is always evicted from memory whenever a put operation fails, then my rehydrating code would assure that in-memory state is always in-sync with storage state.