How-to: Enable and use actor reentrancy in Dapr

Learn more about actor reentrancy

Preview feature

Actor reentrancy is currently in preview.

Actor reentrancy

A core tenet of the virtual actor pattern is the single-threaded nature of actor execution. Before reentrancy, this caused the Dapr runtime to lock an actor on any given request. A second request could not start until the first had completed. This behavior means an actor cannot call itself, or have another actor call into it even if it is part of the same chain. Reentrancy solves this by allowing requests from the same chain or context to re-enter into an already locked actor. Examples of chains that reentrancy allows can be seen below:

  1. Actor A -> Actor A
  2. ActorA -> Actor B -> Actor A

With reentrancy, there can be more complex actor calls without sacrificing the single-threaded behavior of virtual actors.

Enabling actor reentrancy

Actor reentrancy is currently in preview, so enabling it is a two step process.

Preview feature configuration

Before using reentrancy, the feature must be enabled in Dapr. For more information on preview configurations, see the full guide on opting into preview features in Dapr. Below is an example of the configuration for actor reentrancy:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4.   name: reentrantconfig
  5. spec:
  6.   features:
  7.     - name: Actor.Reentrancy
  8.       enabled: true

Actor runtime configuration

Once actor reentrancy is enabled as an opt-in preview feature, the actor that will be reentrant must also provide the appropriate configuration to use reentrancy. This is done by the actor’s endpoint for GET /dapr/config, similar to other actor configuration elements. Here is a snipet of an actor written in Golang providing the configuration:

  1. type daprConfig struct {
  2.     Entities                []string                `json:"entities,omitempty"`
  3.     ActorIdleTimeout        string                  `json:"actorIdleTimeout,omitempty"`
  4.     ActorScanInterval       string                  `json:"actorScanInterval,omitempty"`
  5.     DrainOngoingCallTimeout string                  `json:"drainOngoingCallTimeout,omitempty"`
  6.     DrainRebalancedActors   bool                    `json:"drainRebalancedActors,omitempty"`
  7.     Reentrancy              config.ReentrancyConfig `json:"reentrancy,omitempty"`
  8. }
  10. var daprConfigResponse = daprConfig{
  11.     []string{defaultActorType},
  12.     actorIdleTimeout,
  13.     actorScanInterval,
  14.     drainOngoingCallTimeout,
  15.     drainRebalancedActors,
  16.     config.ReentrancyConfig{Enabled: true, MaxStackDepth: &maxStackDepth},
  17. }
  19. func configHandler(w http.ResponseWriter, r *http.Request) {
  20.     w.Header().Set("Content-Type", "application/json")
  21.     w.WriteHeader(http.StatusOK)
  22.     json.NewEncoder(w).Encode(daprConfigResponse)
  23. }

Handling reentrant requests

The key to a reentrant request is the Dapr-Reentrancy-Id header. The value of this header is used to match requests to their call chain and allow them to bypass the actor’s lock.

The header is generated by the Dapr runtime for any actor request that has a reentrant config specified. Once it is generated, it is used to lock the actor and must be passed to all future requests. Below is a snippet of code from an actor handling this is Golang:

  1. func reentrantCallHandler(w http.ResponseWriter, r *http.Request) {
  2.     /*
  3.      * Omitted.
  4.      */
  6.     req, _ := http.NewRequest("PUT", url, bytes.NewReader(nextBody))
  8.     reentrancyID := r.Header.Get("Dapr-Reentrancy-Id")
  9.     req.Header.Add("Dapr-Reentrancy-Id", reentrancyID)
  11.     client := http.Client{}
  12.     resp, err := client.Do(req)
  14.     /*
  15.      * Omitted.
  16.      */
  17. }

Currently, no SDK supports actor reentrancy. In the future, the method for handling the reentrancy id may be different based on the SDK that is being used.