21 replies

I understand a worker will only be alive

I understand a worker will only be alive for 30 seconds or so.

However, with a durable object, specifically if there is an alarm, how long will the do be alive for?

For example, in an alarm I may potentially have to perform some operation that could take up to 10 minutes to resolve.

Milan•8/5/24, 9:35 PM

Huh... I probably wouldn't advise you to

await

await

a task that takes 10 minutes... In this case, are you able to just run an alarm once every minute or so, each time checking if the result is ready?

BenOP•8/5/24, 9:39 PM

realistically it won't run 10 minutes, but it might take a bit (I need to make up to 1000 fetch calls)

BenOP•8/5/24, 9:39 PM

but I can only make 6 at a time

Milan•8/5/24, 9:40 PM

Ohhh I see

Milan•8/5/24, 9:41 PM

You get 30s of cpu time per incoming request to DOs

Milan•8/5/24, 9:41 PM

So time spent

await

await

ing IO doesn't count

BenOP•8/5/24, 9:41 PM

ahhh

BenOP•8/5/24, 9:41 PM

sweet

BenOP•8/5/24, 9:41 PM

is a alarm considered a "request'

Milan•8/5/24, 9:42 PM

Yep

BenOP•8/5/24, 9:42 PM

ok, and I know DOs can die if there are no requests hitting it, what if the alarm is waiting a while for fetches to reoslve?

Milan•8/5/24, 9:43 PM

This is a common question and we should get better at messaging here. If you have a request come in (in other words, a task is given to the DO) then the "hibernation/clean eviction" won't happen until 10 seconds after that request is done (assuming no other new work is given to the DO)

Milan•8/5/24, 9:44 PM

So basically, if you have an alarm()alarm() run, we're not going to "hibernate" your DO until its done

BenOP•8/5/24, 9:44 PM

fantastic

Milan•8/5/24, 9:44 PM

That said, we could always do a forced eviction/restart because of some other issue, so you should still implement retries

Milan•8/5/24, 9:45 PM

Like if the machine just physically breaks, or if we do a rolling restart to upgrade the runtime (in that case I think executing requests get 30 seconds of walltime to finish up)

Milan•8/5/24, 9:47 PM

Oh uhhh sorry, one thing I should correct: We will do retries for you if the alarm handler throws (which it would if we evicted your DO because of an internal error)

BenOP•8/5/24, 10:18 PM

fantastic

Abakir•8/5/24, 11:28 PM

@Milan I have a question if your alarm is for every day, is the hibernatable durable object going to to sleep until the alarm wakes it up or no?

AAbakir @Milan I have a question if your alarm is for every day, is the hibernatable d...

Milan•8/6/24, 12:04 AM

If your DO isn't handling requests frequently, it will not be "kept hot" in memory (i.e. we will destroy it so another script can use the machine's resources).

"Hibernation" is really a DO + WebSockets specific concept. Historically, when using WebSockets in DOs, we would have to pin your DO to memory for the entire life of the connection. This meant duration bills were quite high, and it wasn't great for customers who had WebSocket servers that only received a few requests sporadically.

"Hibernation" refers to the fact that if you have "hibernatable websockets", then your DO can be destroyed (the isolate with all its memory can go away) but we can re-instantiate your websockets as needed.

AAbakir @Milan I have a question if your alarm is for every day, is the hibernatable d...

Milan•8/6/24, 12:06 AM

So in your case of 1 alarm invocation per day, assuming no other requests go to the DO in the meantime, then 10 seconds after your alarm finishes we will destroy the DO and its associated memory. The next day, when the alarm runs again, we'll load it up into memory and it executes the alarm()alarm() handler.

Abakir•8/6/24, 2:16 AM

Perfect thank you for this information

I understand a worker will only be alive

Similar Threads

Similar Threads

Similar Threads