Skip to content

Commit

Permalink
Fix incorrect statement regarding actor timers (#3977)
Browse files Browse the repository at this point in the history
* update incorrect sentence

Signed-off-by: Hannah Hunter <[email protected]>

* mark edit

Signed-off-by: Hannah Hunter <[email protected]>

---------

Signed-off-by: Hannah Hunter <[email protected]>
Co-authored-by: Mark Fussell <[email protected]>
  • Loading branch information
hhunter-ms and msfussell authored Jan 31, 2024
1 parent 518ef8b commit 1173033
Showing 1 changed file with 3 additions and 1 deletion.
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,9 @@ Now that you've learned about the [actor building block]({{< ref "actors-overvie

Dapr actors are virtual, meaning that their lifetime is not tied to their in-memory representation. As a result, they do not need to be explicitly created or destroyed. The Dapr actor runtime automatically activates an actor the first time it receives a request for that actor ID. If an actor is not used for a period of time, the Dapr actor runtime garbage-collects the in-memory object. It will also maintain knowledge of the actor's existence should it need to be reactivated later.

Invocation of actor methods and reminders reset the idle time, e.g. reminder firing will keep the actor active. Actor reminders fire whether an actor is active or inactive, if fired for inactive actor, it will activate the actor first. Actor timers do not reset the idle time, so timer firing will not keep the actor active. Timers only fire while the actor is active.
Invocation of actor methods, timers, and reminders reset the actor idle time. For example, a reminder firing keeps the actor active.
- Actor reminders fire whether an actor is active or inactive. If fired for an inactive actor, it activates the actor first.
- Actor timers firing reset the idle time; however, timers only fire while the actor is active.

The idle timeout and scan interval Dapr runtime uses to see if an actor can be garbage-collected is configurable. This information can be passed when Dapr runtime calls into the actor service to get supported actor types.

Expand Down

0 comments on commit 1173033

Please sign in to comment.