Merge branch 'v1.13' into quickstarts-java

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.

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
 

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
    ```
 
 

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 >}})