diff --git a/daprdocs/content/en/concepts/service-mesh.md b/daprdocs/content/en/concepts/service-mesh.md index 0e3c4cf9e..d0f686dc3 100644 --- a/daprdocs/content/en/concepts/service-mesh.md +++ b/daprdocs/content/en/concepts/service-mesh.md @@ -7,7 +7,7 @@ description: > How Dapr compares to and works with service meshes --- -Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and distributed tracing. This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others? +Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and [distributed tracing](https://middleware.io/blog/what-is-distributed-tracing/). This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others? ## How Dapr and service meshes compare While Dapr and service meshes do offer some overlapping capabilities, **Dapr is not a service mesh**, where a service mesh is defined as a *networking* service mesh. Unlike a service mesh which is focused on networking concerns, Dapr is focused on providing building blocks that make it easier for developers to build applications as microservices. Dapr is developer-centric, versus service meshes which are infrastructure-centric. diff --git a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md index 167d85f98..afd417515 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md +++ b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md @@ -69,7 +69,7 @@ spec: allowedSecrets: ["secret1", "secret2"] ``` -The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}). +The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}). ## Scenario 3: Deny access to certain sensitive secrets in a secret store @@ -88,7 +88,7 @@ spec: deniedSecrets: ["secret1", "secret2"] ``` -This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}). +This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}). ## Permission priority diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md index b47ed6237..5ac6d287b 100644 --- a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md @@ -61,27 +61,28 @@ Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar the metadata: name: myresiliency scopes: - - checkout - + - order-processor + spec: policies: retries: retryForever: policy: constant - maxInterval: 5s - maxRetries: -1 - + duration: 5s + maxRetries: -1 + circuitBreakers: simpleCB: maxRequests: 1 - timeout: 5s + timeout: 5s trip: consecutiveFailures >= 5 - + targets: - apps: - order-processor: - retry: retryForever - circuitBreaker: simpleCB + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB ``` diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index 8e949e52f..2bc7ca5f9 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -181,6 +181,23 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues. +{{% alert title="Note" color="primary" %}} +Your queue must have the same name as the topic you are publishing to with Dapr. For example, if you are publishing to the pub/sub `"myPubsub"` on the topic `"orders"`, your queue must be named `"orders"`. +If you are using a shared access policy to connect to the queue, that policy must be able to "manage" the queue. To work with a dead-letter queue, the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue. +{{% /alert %}} + +### Retry policy and dead-letter queues + +By default, an Azure Service Bus Queue has a dead-letter queue. The messages are retried the amount given for `maxDeliveryCount`. The default `maxDeliveryCount` value defaults to 10, but can be set up to 2000. These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned. + +Dapr Pub/sub offers its own dead-letter queue concept that lets you control the retry policy and subscribe to the dead-letter queue through Dapr. +1. Set up a separate queue as that dead-letter queue in the Azure Service Bus namespace, and a resilience policy that defines how to retry. +1. Subscribe to the topic to get the failed messages and deal with them. + +For example, setting up a dead-letter queue `orders-dlq` in the subscription and a resiliency policy lets you subscribe to the topic `orders-dlq` to handle failed messages. + +For more details on setting up dead-letter queues, see the [dead-letter article]({{< ref pubsub-deadletter >}}). + ## Related links - [Basic schema for a Dapr component]({{< ref component-schema >}})