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.
13 Replies
Huh... I probably wouldn't advise you to
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?realistically it won't run 10 minutes, but it might take a bit (I need to make up to 1000 fetch calls)
but I can only make 6 at a time
Ohhh I see
You get 30s of cpu time per incoming request to DOs
So time spent
awaiting IO doesn't countahhh
sweet
is a alarm considered a "request'
Yep
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?
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)
So basically, if you have an
alarm() run, we're not going to "hibernate" your DO until its donefantastic
That said, we could always do a forced eviction/restart because of some other issue, so you should still implement retries
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)
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)
fantastic
@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?
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.
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() handler.Perfect thank you for this information