mirror of https://github.com/dapr/docs.git
Merge branch 'v1.10' into issue_3047
Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com>
This commit is contained in:
Hannah Hunter
GitHub
commit
9a0c43793f
|
|
@ -23,7 +23,11 @@ The sidecar APIs are called from your application over local http or gRPC endpoi
|
|||
|
||||
## Self-hosted with `dapr run`
|
||||
|
||||
When Dapr is installed in [self-hosted mode]({{<ref self-hosted>}}), the `daprd` binary is downloaded and placed under the user home directory (`$HOME/.dapr/bin` for Linux/MacOS or `%USERPROFILE%\.dapr\bin\` for Windows). In self-hosted mode, running the Dapr CLI [`run` command]({{< ref dapr-run.md >}}) launches the `daprd` executable together with the provided application executable. This is the recommended way of running the Dapr sidecar when working locally in scenarios such as development and testing. The various arguments the CLI exposes to configure the sidecar can be found in the [Dapr run command reference]({{<ref dapr-run>}}).
|
||||
When Dapr is installed in [self-hosted mode]({{<ref self-hosted>}}), the `daprd` binary is downloaded and placed under the user home directory (`$HOME/.dapr/bin` for Linux/macOS or `%USERPROFILE%\.dapr\bin\` for Windows).
|
||||
|
||||
In self-hosted mode, running the Dapr CLI [`run` command]({{< ref dapr-run.md >}}) launches the `daprd` executable with the provided application executable. This is the recommended way of running the Dapr sidecar when working locally in scenarios such as development and testing.
|
||||
|
||||
You can find the various arguments that the CLI exposes to configure the sidecar in the [Dapr run command reference]({{<ref dapr-run>}}).
|
||||
|
||||
## Kubernetes with `dapr-sidecar-injector`
|
||||
|
||||
|
|
@ -37,7 +41,9 @@ For a detailed list of all available arguments run `daprd --help` or see this [t
|
|||
|
||||
### Examples
|
||||
|
||||
1. Start a sidecar along with an application by specifying its unique ID. Note `--app-id` is a required field:
|
||||
1. Start a sidecar alongside an application by specifying its unique ID.
|
||||
|
||||
**Note:** `--app-id` is a required field, and cannot contain dots.
|
||||
|
||||
```bash
|
||||
daprd --app-id myapp
|
||||
|
|
|
|||
|
|
@ -37,3 +37,10 @@ Dapr provides a way to determine its health using an [HTTP `/healthz` endpoint](
|
|||
- Determined for readiness and liveness
|
||||
|
||||
Read more on about how to apply [dapr health checks]({{< ref sidecar-health >}}) to your application.
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Learn more about resiliency]({{< ref resiliency-overview.md >}})
|
||||
- Try out one of the Resiliency quickstarts:
|
||||
- [Resiliency: Service-to-service]({{< ref resiliency-serviceinvo-quickstart.md >}})
|
||||
- [Resiliency: State Management]({{< ref resiliency-state-quickstart.md >}})
|
||||
|
|
@ -0,0 +1,285 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Publish and subscribe to bulk messages"
|
||||
linkTitle: "Publish and subscribe to bulk messages"
|
||||
weight: 7100
|
||||
description: "Learn how to use the bulk publish and subscribe APIs in Dapr."
|
||||
---
|
||||
|
||||
{{% alert title="alpha" color="warning" %}}
|
||||
The bulk publish and subscribe APIs are in **alpha** stage.
|
||||
{{% /alert %}}
|
||||
|
||||
With the bulk publish and subscribe APIs, you can publish and subscribe to multiple messages in a single request. When writing applications that need to send or receive a large number of messages, using bulk operations allows achieving high throughput by reducing the overall number of requests between the Dapr sidecar, the application, and the underlying pub/sub broker.
|
||||
|
||||
## Publishing messages in bulk
|
||||
|
||||
### Restrictions when publishing messages in bulk
|
||||
|
||||
The bulk publish API allows you to publish multiple messages to a topic in a single request. It is *non-transactional*, i.e., from a single bulk request, some messages can succeed and some can fail. If any of the messages fail to publish, the bulk publish operation returns a list of failed messages.
|
||||
|
||||
The bulk publish operation also does not guarantee any ordering of messages.
|
||||
|
||||
### Example
|
||||
|
||||
{{< tabs Java Javascript Dotnet Python Go "HTTP API (Bash)" "HTTP API (PowerShell)" >}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```java
|
||||
import io.dapr.client.DaprClientBuilder;
|
||||
import io.dapr.client.DaprPreviewClient;
|
||||
import io.dapr.client.domain.BulkPublishResponse;
|
||||
import io.dapr.client.domain.BulkPublishResponseFailedEntry;
|
||||
import java.util.ArrayList;
|
||||
import java.util.List;
|
||||
|
||||
class BulkPublisher {
|
||||
private static final String PUBSUB_NAME = "my-pubsub-name";
|
||||
private static final String TOPIC_NAME = "topic-a";
|
||||
|
||||
public void publishMessages() {
|
||||
try (DaprPreviewClient client = (new DaprClientBuilder()).buildPreviewClient()) {
|
||||
// Create a list of messages to publish
|
||||
List<String> messages = new ArrayList<>();
|
||||
for (int i = 0; i < 10; i++) {
|
||||
String message = String.format("This is message #%d", i);
|
||||
messages.add(message);
|
||||
}
|
||||
|
||||
// Publish list of messages using the bulk publish API
|
||||
BulkPublishResponse<String> res = client.publishEvents(PUBSUB_NAME, TOPIC_NAME, "text/plain", messages).block();
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```typescript
|
||||
|
||||
import { DaprClient } from "@dapr/dapr";
|
||||
|
||||
const pubSubName = "my-pubsub-name";
|
||||
const topic = "topic-a";
|
||||
|
||||
async function start() {
|
||||
const client = new DaprClient();
|
||||
|
||||
// Publish multiple messages to a topic.
|
||||
await client.pubsub.publishBulk(pubSubName, topic, ["message 1", "message 2", "message 3"]);
|
||||
|
||||
// Publish multiple messages to a topic with explicit bulk publish messages.
|
||||
const bulkPublishMessages = [
|
||||
{
|
||||
entryID: "entry-1",
|
||||
contentType: "application/json",
|
||||
event: { hello: "foo message 1" },
|
||||
},
|
||||
{
|
||||
entryID: "entry-2",
|
||||
contentType: "application/cloudevents+json",
|
||||
event: {
|
||||
specversion: "1.0",
|
||||
source: "/some/source",
|
||||
type: "example",
|
||||
id: "1234",
|
||||
data: "foo message 2",
|
||||
datacontenttype: "text/plain"
|
||||
},
|
||||
},
|
||||
{
|
||||
entryID: "entry-3",
|
||||
contentType: "text/plain",
|
||||
event: "foo message 3",
|
||||
},
|
||||
];
|
||||
await client.pubsub.publishBulk(pubSubName, topic, bulkPublishMessages);
|
||||
}
|
||||
|
||||
start().catch((e) => {
|
||||
console.error(e);
|
||||
process.exit(1);
|
||||
});
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```csharp
|
||||
using System;
|
||||
using System.Collections.Generic;
|
||||
using Dapr.Client;
|
||||
|
||||
const string PubsubName = "my-pubsub-name";
|
||||
const string TopicName = "topic-a";
|
||||
IReadOnlyList<object> BulkPublishData = new List<object>() {
|
||||
new { Id = "17", Amount = 10m },
|
||||
new { Id = "18", Amount = 20m },
|
||||
new { Id = "19", Amount = 30m }
|
||||
};
|
||||
|
||||
using var client = new DaprClientBuilder().Build();
|
||||
|
||||
var res = await client.BulkPublishEventAsync(PubsubName, TopicName, BulkPublishData);
|
||||
if (res == null) {
|
||||
throw new Exception("null response from dapr");
|
||||
}
|
||||
if (res.FailedEntries.Count > 0)
|
||||
{
|
||||
Console.WriteLine("Some events failed to be published!");
|
||||
foreach (var failedEntry in res.FailedEntries)
|
||||
{
|
||||
Console.WriteLine("EntryId: " + failedEntry.Entry.EntryId + " Error message: " +
|
||||
failedEntry.ErrorMessage);
|
||||
}
|
||||
}
|
||||
else
|
||||
{
|
||||
Console.WriteLine("Published all events!");
|
||||
}
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```python
|
||||
import requests
|
||||
import json
|
||||
|
||||
base_url = "http://localhost:3500/v1.0-alpha1/publish/bulk/{}/{}"
|
||||
pubsub_name = "my-pubsub-name"
|
||||
topic_name = "topic-a"
|
||||
payload = [
|
||||
{
|
||||
"entryId": "ae6bf7c6-4af2-11ed-b878-0242ac120002",
|
||||
"event": "first text message",
|
||||
"contentType": "text/plain"
|
||||
},
|
||||
{
|
||||
"entryId": "b1f40bd6-4af2-11ed-b878-0242ac120002",
|
||||
"event": {
|
||||
"message": "second JSON message"
|
||||
},
|
||||
"contentType": "application/json"
|
||||
}
|
||||
]
|
||||
|
||||
response = requests.post(base_url.format(pubsub_name, topic_name), json=payload)
|
||||
print(response.status_code)
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
"strings"
|
||||
"net/http"
|
||||
"io/ioutil"
|
||||
)
|
||||
|
||||
const (
|
||||
pubsubName = "my-pubsub-name"
|
||||
topicName = "topic-a"
|
||||
baseUrl = "http://localhost:3500/v1.0-alpha1/publish/bulk/%s/%s"
|
||||
)
|
||||
|
||||
func main() {
|
||||
url := fmt.Sprintf(baseUrl, pubsubName, topicName)
|
||||
method := "POST"
|
||||
payload := strings.NewReader(`[
|
||||
{
|
||||
"entryId": "ae6bf7c6-4af2-11ed-b878-0242ac120002",
|
||||
"event": "first text message",
|
||||
"contentType": "text/plain"
|
||||
},
|
||||
{
|
||||
"entryId": "b1f40bd6-4af2-11ed-b878-0242ac120002",
|
||||
"event": {
|
||||
"message": "second JSON message"
|
||||
},
|
||||
"contentType": "application/json"
|
||||
}
|
||||
]`)
|
||||
|
||||
client := &http.Client {}
|
||||
req, _ := http.NewRequest(method, url, payload)
|
||||
|
||||
req.Header.Add("Content-Type", "application/json")
|
||||
res, err := client.Do(req)
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:3500/v1.0-alpha1/publish/bulk/my-pubsub-name/topic-a \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '[
|
||||
{
|
||||
"entryId": "ae6bf7c6-4af2-11ed-b878-0242ac120002",
|
||||
"event": "first text message",
|
||||
"contentType": "text/plain"
|
||||
},
|
||||
{
|
||||
"entryId": "b1f40bd6-4af2-11ed-b878-0242ac120002",
|
||||
"event": {
|
||||
"message": "second JSON message"
|
||||
},
|
||||
"contentType": "application/json"
|
||||
},
|
||||
]'
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{% codetab %}}
|
||||
|
||||
```powershell
|
||||
Invoke-RestMethod -Method Post -ContentType 'application/json' -Uri 'http://localhost:3500/v1.0-alpha1/publish/bulk/my-pubsub-name/topic-a' `
|
||||
-Body '[
|
||||
{
|
||||
"entryId": "ae6bf7c6-4af2-11ed-b878-0242ac120002",
|
||||
"event": "first text message",
|
||||
"contentType": "text/plain"
|
||||
},
|
||||
{
|
||||
"entryId": "b1f40bd6-4af2-11ed-b878-0242ac120002",
|
||||
"event": {
|
||||
"message": "second JSON message"
|
||||
},
|
||||
"contentType": "application/json"
|
||||
},
|
||||
]'
|
||||
```
|
||||
|
||||
{{% /codetab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
## How components handle publishing and subscribing to bulk messages
|
||||
|
||||
Some pub/sub brokers support sending and receiving multiple messages in a single request. When a component supports bulk publish or subscribe operations, Dapr runtime uses them to further optimize the communication between the Dapr sidecar and the underlying pub/sub broker.
|
||||
|
||||
For components that do not have bulk publish or subscribe support, Dapr runtime uses the regular publish and subscribe APIs to send and receive messages one by one. This is still more efficient than directly using the regular publish or subscribe APIs, because applications can still send/receive multiple messages in a single request to/from Dapr.
|
||||
|
||||
## Supported components
|
||||
|
||||
Refer to the [component reference]({{< ref supported-pubsub >}}) to see which components support bulk publish and subscribe operations.
|
||||
|
||||
## Related links
|
||||
|
||||
- List of [supported pub/sub components]({{< ref supported-pubsub >}})
|
||||
- Read the [API reference]({{< ref pubsub_api.md >}})
|
||||
|
|
@ -119,6 +119,10 @@ By default, all topic messages associated with an instance of a pub/sub componen
|
|||
|
||||
Dapr can set a timeout message on a per-message basis, meaning that if the message is not read from the pub/sub component, then the message is discarded. This timeout message prevents a build up of unread messages. If a message has been in the queue longer than the configured TTL, it is marked as dead. For more information, read [pub/sub message TTL]({{< ref pubsub-message-ttl.md >}}).
|
||||
|
||||
### Publish and subscribe to bulk messages
|
||||
|
||||
Dapr supports sending and receiving multiple messages in a single request. When writing applications that need to send or receive a large number of messages, using bulk operations allows achieving high throughput by reducing the overall number of requests. For more information, read [pub/sub bulk messages]({{< ref pubsub-bulk.md >}}).
|
||||
|
||||
## Try out pub/sub
|
||||
|
||||
### Quickstarts and tutorials
|
||||
|
|
|
|||
|
|
@ -199,11 +199,10 @@ namespace EventService
|
|||
System.Threading.Thread.Sleep(5000);
|
||||
Random random = new Random();
|
||||
int orderId = random.Next(1,1000);
|
||||
CancellationTokenSource source = new CancellationTokenSource();
|
||||
CancellationToken cancellationToken = source.Token;
|
||||
using var client = new DaprClientBuilder().Build();
|
||||
|
||||
//Using Dapr SDK to invoke a method
|
||||
var result = client.CreateInvokeMethodRequest(HttpMethod.Get, "checkout", "checkout/" + orderId, cancellationToken);
|
||||
var result = client.CreateInvokeMethodRequest(HttpMethod.Get, "checkout", "checkout/" + orderId);
|
||||
await client.InvokeMethodAsync(result);
|
||||
Console.WriteLine("Order requested: " + orderId);
|
||||
Console.WriteLine("Result: " + result);
|
||||
|
|
|
|||
|
|
@ -6,10 +6,6 @@ weight: 120
|
|||
description: "Get started with Dapr's resiliency capabilities via the service invocation API"
|
||||
---
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Resiliency is currently a preview feature.
|
||||
{{% /alert %}}
|
||||
|
||||
Observe Dapr resiliency capabilities by simulating a system failure. In this Quickstart, you will:
|
||||
|
||||
- Run two microservice applications: `checkout` and `order-processor`. `checkout` will continuously make Dapr service invocation requests to `order-processor`.
|
||||
|
|
@ -59,10 +55,10 @@ pip3 install -r requirements.txt
|
|||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-port 8001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- python3 app.py
|
||||
dapr run --app-port 8001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- python3 app.py
|
||||
```
|
||||
|
||||
### Step 3: Run the `checkout` service application with resiliency enabled
|
||||
### Step 3: Run the `checkout` service application
|
||||
|
||||
In a new terminal window, from the root of the Quickstart directory, navigate to the `checkout` directory.
|
||||
|
||||
|
|
@ -76,13 +72,13 @@ Install dependencies:
|
|||
pip3 install -r requirements.txt
|
||||
```
|
||||
|
||||
Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature.
|
||||
Run the `checkout` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- python3 app.py
|
||||
dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- python3 app.py
|
||||
```
|
||||
|
||||
By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar:
|
||||
The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -287,10 +283,10 @@ npm install
|
|||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-port 5001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- npm start
|
||||
dapr run --app-port 5001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- npm start
|
||||
```
|
||||
|
||||
### Step 3: Run the `checkout` service application with resiliency enabled
|
||||
### Step 3: Run the `checkout` service application
|
||||
|
||||
In a new terminal window, from the root of the Quickstart directory,
|
||||
navigate to the `checkout` directory.
|
||||
|
|
@ -305,13 +301,14 @@ Install dependencies:
|
|||
npm install
|
||||
```
|
||||
|
||||
Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature.
|
||||
Run the `checkout` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- npm start
|
||||
dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- npm start
|
||||
```
|
||||
|
||||
By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar:
|
||||
The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -450,7 +447,7 @@ Once you restart the `order-processor` service, the application will recover sea
|
|||
In the `order-processor` service terminal, restart the application:
|
||||
|
||||
```bash
|
||||
dapr run --app-port 5001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- npm start
|
||||
dapr run --app-port 5001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- npm start
|
||||
```
|
||||
|
||||
`checkout` service output:
|
||||
|
|
@ -518,10 +515,10 @@ dotnet build
|
|||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-port 7001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- dotnet run
|
||||
dapr run --app-port 7001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- dotnet run
|
||||
```
|
||||
|
||||
### Step 3: Run the `checkout` service application with resiliency enabled
|
||||
### Step 3: Run the `checkout` service application
|
||||
|
||||
In a new terminal window, from the root of the Quickstart directory,
|
||||
navigate to the `checkout` directory.
|
||||
|
|
@ -537,13 +534,13 @@ dotnet restore
|
|||
dotnet build
|
||||
```
|
||||
|
||||
Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature.
|
||||
Run the `checkout` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- dotnet run
|
||||
dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- dotnet run
|
||||
```
|
||||
|
||||
By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar:
|
||||
The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -751,10 +748,10 @@ mvn clean install
|
|||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar
|
||||
dapr run --app-id order-processor --resources-path ../../../resources/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar
|
||||
```
|
||||
|
||||
### Step 3: Run the `checkout` service application with resiliency enabled
|
||||
### Step 3: Run the `checkout` service application
|
||||
|
||||
In a new terminal window, from the root of the Quickstart directory,
|
||||
navigate to the `checkout` directory.
|
||||
|
|
@ -769,13 +766,14 @@ Install dependencies:
|
|||
mvn clean install
|
||||
```
|
||||
|
||||
Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature.
|
||||
Run the `checkout` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- java -jar target/CheckoutService-0.0.1-SNAPSHOT.jar
|
||||
dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- java -jar target/CheckoutService-0.0.1-SNAPSHOT.jar
|
||||
```
|
||||
|
||||
By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar:
|
||||
The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -914,7 +912,7 @@ Once you restart the `order-processor` service, the application will recover sea
|
|||
In the `order-processor` service terminal, restart the application:
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar
|
||||
dapr run --app-id order-processor --resources-path ../../../resources/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar
|
||||
```
|
||||
|
||||
`checkout` service output:
|
||||
|
|
@ -980,10 +978,10 @@ go build .
|
|||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-port 6001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- go run .
|
||||
dapr run --app-port 6001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- go run .
|
||||
```
|
||||
|
||||
### Step 3: Run the `checkout` service application with resiliency enabled
|
||||
### Step 3: Run the `checkout` service application
|
||||
|
||||
In a new terminal window, from the root of the Quickstart directory,
|
||||
navigate to the `checkout` directory.
|
||||
|
|
@ -998,13 +996,14 @@ Install dependencies:
|
|||
go build .
|
||||
```
|
||||
|
||||
Run the `checkout` service alongside a Dapr sidecar. The `--config` parameter applies a Dapr configuration that enables the resiliency feature.
|
||||
Run the `checkout` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-id checkout --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3500 -- go run .
|
||||
dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- go run .
|
||||
```
|
||||
|
||||
By enabling resiliency, the resiliency spec located in the components directory is detected and loaded by the Dapr sidecar:
|
||||
The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -1143,7 +1142,7 @@ Once you restart the `order-processor` service, the application will recover sea
|
|||
In the `order-processor` service terminal, restart the application:
|
||||
|
||||
```bash
|
||||
dapr run --app-port 6001 --app-id order-processor --config ../config.yaml --components-path ../../../components/ --app-protocol http --dapr-http-port 3501 -- go run .
|
||||
dapr run --app-port 6001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- go run .
|
||||
```
|
||||
|
||||
`checkout` service output:
|
||||
|
|
|
|||
|
|
@ -6,13 +6,9 @@ weight: 110
|
|||
description: "Get started with Dapr's resiliency capabilities via the state management API"
|
||||
---
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Resiliency is currently a preview feature.
|
||||
{{% /alert %}}
|
||||
|
||||
Observe Dapr resiliency capabilities by simulating a system failure. In this Quickstart, you will:
|
||||
|
||||
- Execute a microservice application with resiliency enabled that continuously persists and retrieves state via Dapr's state management API.
|
||||
- Execute a microservice application that continuously persists and retrieves state via Dapr's state management API.
|
||||
- Trigger resiliency policies by simulating a system failure.
|
||||
- Resolve the failure and the microservice application will resume.
|
||||
|
||||
|
|
@ -54,9 +50,10 @@ Install dependencies
|
|||
pip3 install -r requirements.txt
|
||||
```
|
||||
|
||||
### Step 2: Run the application with resiliency enabled
|
||||
### Step 2: Run the application
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -89,7 +86,7 @@ Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` co
|
|||
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- python3
|
||||
dapr run --app-id order-processor --resources-path ../../../resources/ -- python3
|
||||
```
|
||||
|
||||
Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}).
|
||||
|
|
@ -132,7 +129,7 @@ Once Redis is stopped, the requests begin to fail and the retry policy titled `r
|
|||
INFO[0006] Error processing operation component[statestore] output. Retrying...
|
||||
```
|
||||
|
||||
As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
As per the `retryForever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
|
||||
```yaml
|
||||
retryForever:
|
||||
|
|
@ -223,9 +220,10 @@ Install dependencies
|
|||
npm install
|
||||
```
|
||||
|
||||
### Step 2: Run the application with resiliency enabled
|
||||
### Step 2: Run the application
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -257,7 +255,7 @@ Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` co
|
|||
```
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- npm start
|
||||
dapr run --app-id order-processor --resources-path ../../../resources/ -- npm start
|
||||
```
|
||||
|
||||
Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}).
|
||||
|
|
@ -300,7 +298,7 @@ Once Redis is stopped, the requests begin to fail and the retry policy titled `r
|
|||
INFO[0006] Error processing operation component[statestore] output. Retrying...
|
||||
```
|
||||
|
||||
As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
As per the `retryForever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
|
||||
```yaml
|
||||
retryForever:
|
||||
|
|
@ -392,9 +390,9 @@ dotnet restore
|
|||
dotnet build
|
||||
```
|
||||
|
||||
### Step 2: Run the application with resiliency enabled
|
||||
### Step 2: Run the application
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is:
|
||||
Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -426,7 +424,7 @@ Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` co
|
|||
```
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- dotnet run
|
||||
dapr run --app-id order-processor --resources-path ../../../resources/ -- dotnet run
|
||||
```
|
||||
|
||||
Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}).
|
||||
|
|
@ -469,7 +467,7 @@ Once Redis is stopped, the requests begin to fail and the retry policy titled `r
|
|||
INFO[0006] Error processing operation component[statestore] output. Retrying...
|
||||
```
|
||||
|
||||
As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
As per the `retryForever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
|
||||
```yaml
|
||||
retryForever:
|
||||
|
|
@ -563,9 +561,9 @@ Install dependencies
|
|||
mvn clean install
|
||||
```
|
||||
|
||||
### Step 2: Run the application with resiliency enabled
|
||||
### Step 2: Run the application
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is:
|
||||
Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -597,7 +595,7 @@ Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` co
|
|||
```
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components/ -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar
|
||||
dapr run --app-id order-processor --resources-path ../../../resources/ -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar
|
||||
```
|
||||
|
||||
Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}).
|
||||
|
|
@ -640,7 +638,7 @@ Once Redis is stopped, the requests begin to fail and the retry policy titled `r
|
|||
INFO[0006] Error processing operation component[statestore] output. Retrying...
|
||||
```
|
||||
|
||||
As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
As per the `retryForever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
|
||||
```yaml
|
||||
retryForever:
|
||||
|
|
@ -731,9 +729,9 @@ Install dependencies
|
|||
go build .
|
||||
```
|
||||
|
||||
### Step 2: Run the application with resiliency enabled
|
||||
### Step 2: Run the application
|
||||
|
||||
Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` command below, the `--config` parameter applies a Dapr configuration that enables the resiliency feature. By enabling resiliency, the resiliency spec located in the components directory is loaded by the `order-processor` sidecar. The resilency spec is:
|
||||
Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar then loads the resiliency spec located in the resources directory:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -765,7 +763,7 @@ Run the `order-processor` service alongside a Dapr sidecar. In the `dapr run` co
|
|||
```
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --config ../config.yaml --components-path ../../../components -- go run .
|
||||
dapr run --app-id order-processor --resources-path ../../../resources -- go run .
|
||||
```
|
||||
|
||||
Once the application has started, the `order-processor`service writes and reads `orderId` key/value pairs to the `statestore` Redis instance [defined in the `statestore.yaml` component]({{< ref "statemanagement-quickstart.md#statestoreyaml-component-file" >}}).
|
||||
|
|
@ -808,7 +806,7 @@ Once Redis is stopped, the requests begin to fail and the retry policy titled `r
|
|||
INFO[0006] Error processing operation component[statestore] output. Retrying...
|
||||
```
|
||||
|
||||
As per the `retryFroever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
As per the `retryForever` policy, retries will continue for each failed request indefinitely, in 5 second intervals.
|
||||
|
||||
```yaml
|
||||
retryForever:
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Since you are running Dapr in the same host as the component, verify this folder
|
|||
|
||||
Define your component using a [component spec]({{< ref component-schema.md >}}). Your component's `type` is derived from the socket name, without the file extension.
|
||||
|
||||
Save the component YAML file in the components-path, replacing:
|
||||
Save the component YAML file in the resources-path, replacing:
|
||||
|
||||
- `your_socket_goes_here` with your component socket name (no extension)
|
||||
- `your_component_type` with your component type
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ type: docs
|
|||
title: "Policies"
|
||||
linkTitle: "Policies"
|
||||
weight: 4500
|
||||
description: "Configure resiliency policies for timeouts, retries and circuit breakers"
|
||||
description: "Configure resiliency policies for timeouts, retries, and circuit breakers"
|
||||
---
|
||||
|
||||
You define timeouts, retries and circuit breaker policies under `policies`. Each policy is given a name so you can refer to them from the `targets` section in the resiliency spec.
|
||||
Define timeouts, retries, and circuit breaker policies under `policies`. Each policy is given a name so you can refer to them from the `targets` section in the resiliency spec.
|
||||
|
||||
> Note: Dapr offers default retries for specific APIs. [See here]({{< ref "#override-default-retries" >}}) to learn how you can overwrite default retry logic with user defined retry policies.
|
||||
|
||||
|
|
@ -286,3 +286,9 @@ The table below is a break down of which policies are applied when attempting to
|
|||
| actorstore | fastRetries |
|
||||
| EventActor | retryForever |
|
||||
| SummaryActor | DefaultActorRetryPolicy |
|
||||
|
||||
## Next steps
|
||||
|
||||
Try out one of the Resiliency quickstarts:
|
||||
- [Resiliency: Service-to-service]({{< ref resiliency-serviceinvo-quickstart.md >}})
|
||||
- [Resiliency: State Management]({{< ref resiliency-state-quickstart.md >}})
|
||||
|
|
@ -5,9 +5,6 @@ linkTitle: "Overview"
|
|||
weight: 4500
|
||||
description: "Configure Dapr retries, timeouts, and circuit breakers"
|
||||
---
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Resiliency is currently a preview feature. Before you can utilize a resiliency spec, you must first [enable the resiliency preview feature]({{< ref support-preview-features >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
Dapr provides a capability for defining and applying fault tolerance resiliency policies via a [resiliency spec]({{< ref "resiliency-overview.md#complete-example-policy" >}}). Resiliency specs are saved in the same location as components specs and are applied when the Dapr sidecar starts. The sidecar determines how to apply resiliency policies to your Dapr API calls. In self-hosted mode, the resiliency spec must be named `resiliency.yaml`. In Kubernetes Dapr finds the named resiliency specs used by your application. Within the resiliency spec, you can define policies for popular resiliency patterns, such as:
|
||||
|
||||
|
|
@ -171,3 +168,9 @@ Watch this video for how to use [resiliency](https://www.youtube.com/watch?t=184
|
|||
|
||||
- [Policies]({{< ref "policies.md" >}})
|
||||
- [Targets]({{< ref "targets.md" >}})
|
||||
|
||||
## Next steps
|
||||
|
||||
Try out one of the Resiliency quickstarts:
|
||||
- [Resiliency: Service-to-service]({{< ref resiliency-serviceinvo-quickstart.md >}})
|
||||
- [Resiliency: State Management]({{< ref resiliency-state-quickstart.md >}})
|
||||
|
|
@ -7,6 +7,7 @@ description: "Apply resiliency policies to apps, components and actors"
|
|||
---
|
||||
|
||||
### Targets
|
||||
|
||||
Named policies are applied to targets. Dapr supports three target types that apply all Dapr building block APIs:
|
||||
- `apps`
|
||||
- `components`
|
||||
|
|
@ -130,3 +131,9 @@ spec:
|
|||
circuitBreakerScope: both
|
||||
circuitBreakerCacheSize: 5000
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
Try out one of the Resiliency quickstarts:
|
||||
- [Resiliency: Service-to-service]({{< ref resiliency-serviceinvo-quickstart.md >}})
|
||||
- [Resiliency: State Management]({{< ref resiliency-state-quickstart.md >}})
|
||||
|
|
@ -16,7 +16,6 @@ For CLI there is no explicit opt-in, just the version that this was first made a
|
|||
| Feature | Description | Setting | Documentation | Version introduced |
|
||||
| ---------- |-------------|---------|---------------|-----------------|
|
||||
| **`--image-registry`** flag in Dapr CLI| In self hosted mode you can set this flag to specify any private registry to pull the container images required to install Dapr| N/A | [CLI init command reference]({{<ref "dapr-init.md#self-hosted-environment" >}}) | v1.7 |
|
||||
| **Resiliency** | Allows configuring of fine-grained policies for retries, timeouts and circuitbreaking. | `Resiliency` | [Configure Resiliency Policies]({{<ref "resiliency-overview">}}) | v1.7|
|
||||
| **App Middleware** | Allow middleware components to be executed when making service-to-service calls | N/A | [App Middleware]({{<ref "middleware.md#app-middleware" >}}) | v1.9 |
|
||||
| **App health checks** | Allows configuring app health checks | `AppHealthCheck` | [App health checks]({{<ref "app-health.md" >}}) | v1.9 |
|
||||
| **Pluggable components** | Allows creating self-hosted gRPC-based components written in any language that supports gRPC. The following component APIs are supported: State stores, Pub/sub, Bindings | N/A | [Pluggable components concept]({{<ref "components-concept#pluggable-components" >}})| v1.9 |
|
||||
|
|
|
|||
|
|
@ -64,6 +64,90 @@ Parameter | Description
|
|||
|
||||
> Additional metadata parameters are available based on each pubsub component.
|
||||
|
||||
## Publish multiple messages to a given topic
|
||||
|
||||
This endpoint lets you publish multiple messages to consumers who are listening on a `topic`.
|
||||
|
||||
### HTTP Request
|
||||
|
||||
```
|
||||
POST http://localhost:<daprPort>/v1.0-alpha1/publish/bulk/<pubsubname>/<topic>[?<metadata>]
|
||||
```
|
||||
|
||||
The request body should contain a JSON array of entries with:
|
||||
- Unique entry IDs
|
||||
- The event to publish
|
||||
- The content type of the event
|
||||
|
||||
If the content type for an event is not `application/cloudevents+json`, it is auto-wrapped as a CloudEvent (unless `metadata.rawPayload` is set to `true`).
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:3500/v1.0-alpha1/publish/bulk/pubsubName/deathStarStatus \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '[
|
||||
{
|
||||
"entryId": "ae6bf7c6-4af2-11ed-b878-0242ac120002",
|
||||
"event": "first text message",
|
||||
"contentType": "text/plain"
|
||||
},
|
||||
{
|
||||
"entryId": "b1f40bd6-4af2-11ed-b878-0242ac120002",
|
||||
"event": {
|
||||
"message": "second JSON message"
|
||||
},
|
||||
"contentType": "application/json"
|
||||
},
|
||||
]'
|
||||
```
|
||||
|
||||
### Headers
|
||||
|
||||
The `Content-Type` header should always be set to `application/json` since the request body is a JSON array.
|
||||
|
||||
### URL Parameters
|
||||
|
||||
|**Parameter**|**Description**|
|
||||
|--|--|
|
||||
|`daprPort`|The Dapr port|
|
||||
|`pubsubname`|The name of pub/sub component|
|
||||
|`topic`|The name of the topic|
|
||||
|`metadata`|Query parameters for [metadata]({{< ref "pubsub_api.md#metadata" >}})|
|
||||
|
||||
### Metadata
|
||||
|
||||
Metadata can be sent via query parameters in the request's URL. It must be prefixed with `metadata.`, as shown in the table below.
|
||||
|
||||
|**Parameter**|**Description**|
|
||||
|--|--|
|
||||
|`metadata.rawPayload`|Boolean to determine if Dapr should publish the messages without wrapping them as CloudEvent.|
|
||||
|`metadata.maxBulkPubBytes`|Maximum bytes to publish in a bulk publish request.|
|
||||
|
||||
|
||||
#### HTTP Response
|
||||
|
||||
|**HTTP Status**|**Description**|
|
||||
|--|--|
|
||||
|204|All messages delivered|
|
||||
|400|Pub/sub does not exist|
|
||||
|403|Forbidden by access controls|
|
||||
|500|At least one message failed to be delivered|
|
||||
|
||||
In case of a 500 status code, the response body will contain a JSON object containing a list of entries that failed to be delivered. For example from our request above, if the entry with event `"first text message"` failed to be delivered, the response would contain its entry ID and an error message from the underlying pub/sub component.
|
||||
|
||||
```json
|
||||
{
|
||||
"failedEntries": [
|
||||
{
|
||||
"entryId": "ae6bf7c6-4af2-11ed-b878-0242ac120002",
|
||||
"error": "some error message"
|
||||
},
|
||||
],
|
||||
"errorCode": "ERR_PUBSUB_PUBLISH_MESSAGE"
|
||||
}
|
||||
```
|
||||
|
||||
## Optional Application (User Code) Routes
|
||||
|
||||
### Provide a route for Dapr to discover topic subscriptions
|
||||
|
|
|
|||
|
|
@ -23,12 +23,11 @@ dapr run [flags] [command]
|
|||
|
||||
| Name | Environment Variable | Default | Description |
|
||||
| ------------------------------ | -------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| `--app-id`, `-a` | `APP_ID` | | The id for your application, used for service discovery |
|
||||
| `--app-id`, `-a` | `APP_ID` | | The id for your application, used for service discovery. Cannot contain dots. |
|
||||
| `--app-max-concurrency` | | `unlimited` | The concurrency level of the application; default is unlimited |
|
||||
| `--app-port`, `-p` | `APP_PORT` | | The port your application is listening on |
|
||||
| `--app-protocol`, `-P` | | `http` | The protocol Dapr uses to talk to the application. Valid values are: `http` or `grpc` |
|
||||
| `--app-ssl` | | `false` | Enable https when Dapr invokes the application |
|
||||
| `--components-path`, `-d` | | Linux/Mac: `$HOME/.dapr/components` <br/>Windows: `%USERPROFILE%\.dapr\components` | **Deprecated** in favor of `--resources-path` |
|
||||
| `--resources-path`, `-d` | | Linux/Mac: `$HOME/.dapr/components` <br/>Windows: `%USERPROFILE%\.dapr\components` | The path for components directory |
|
||||
| `--config`, `-c` | | Linux/Mac: `$HOME/.dapr/config.yaml` <br/>Windows: `%USERPROFILE%\.dapr\config.yaml` | Dapr configuration file |
|
||||
| `--dapr-grpc-port` | `DAPR_GRPC_PORT` | `50001` | The gRPC port for Dapr to listen on |
|
||||
|
|
@ -49,6 +48,7 @@ dapr run [flags] [command]
|
|||
| `--unix-domain-socket`, `-u` | | | Path to a unix domain socket dir mount. If specified, communication with the Dapr sidecar uses unix domain sockets for lower latency and greater throughput when compared to using TCP ports. Not available on Windows. |
|
||||
| `--dapr-http-max-request-size` | | `4` | Max size of the request body in MB. |
|
||||
| `--dapr-http-read-buffer-size` | | `4` | Max size of the HTTP read buffer in KB. This also limits the maximum size of HTTP headers. The default 4 KB |
|
||||
| `--components-path`, `-d` | | Linux/Mac: `$HOME/.dapr/components` <br/>Windows: `%USERPROFILE%\.dapr\components` | **Deprecated** in favor of `--resources-path` |
|
||||
|
||||
### Examples
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,18 @@ spec:
|
|||
metadata:
|
||||
- name: url
|
||||
value: http://something.com
|
||||
- name: MTLSRootCA
|
||||
value: /Users/somepath/root.pem # OPTIONAL <path to root CA> or <pem encoded string>
|
||||
- name: MTLSClientCert
|
||||
value: /Users/somepath/client.pem # OPTIONAL <path to client cert> or <pem encoded string>
|
||||
- name: MTLSClientKey
|
||||
value: /Users/somepath/client.key # OPTIONAL <path to client key> or <pem encoded string>
|
||||
- name: securityToken # OPTIONAL <token to include as a header on HTTP requests>
|
||||
secretKeyRef:
|
||||
name: mysecret
|
||||
key: mytoken
|
||||
- name: securityTokenHeader
|
||||
value: "Authorization: Bearer" # OPTIONAL <header name for the security token>
|
||||
```
|
||||
|
||||
## Spec metadata fields
|
||||
|
|
@ -27,6 +39,11 @@ spec:
|
|||
| Field | Required | Binding support | Details | Example |
|
||||
|--------------------|:--------:|--------|--------|---------|
|
||||
| url | Y | Output |The base URL of the HTTP endpoint to invoke | `http://host:port/path`, `http://myservice:8000/customers`
|
||||
| MTLSRootCA | N | Output |Path to root ca certificate or pem encoded string |
|
||||
| MTLSClientCert | N | Output |Path to client certificate or pem encoded string |
|
||||
| MTLSClientKey | N | Output |Path client private key or pem encoded string |
|
||||
| securityToken | N | Output |The value of a token to be added to an HTTP request as a header. Used together with `securityTokenHeader` |
|
||||
| securityTokenHeader| N | Output |The name of the header for `securityToken` on an HTTP request that |
|
||||
|
||||
## Binding support
|
||||
|
||||
|
|
@ -292,6 +309,17 @@ curl -d '{ "operation": "get" }' \
|
|||
|
||||
{{< /tabs >}}
|
||||
|
||||
## Using mTLS or enabling client TLS authentication along with HTTPS
|
||||
You can configure the HTTP binding to use mTLS or client TLS authentication along with HTTPS by providing the `MTLSRootCA`, `MTLSClientCert`, and `MTLSClientKey` metadata fields in the binding component.
|
||||
|
||||
These fields can be passed as a file path or as a pem encoded string.
|
||||
- If the file path is provided, the file is read and the contents are used.
|
||||
- If the pem encoded string is provided, the string is used as is.
|
||||
When these fields are configured, the Dapr sidecar uses the provided certificate to authenticate itself with the server during the TLS handshake process.
|
||||
|
||||
### When to use:
|
||||
You can use this when the server with which the HTTP binding is configured to communicate requires mTLS or client TLS authentication.
|
||||
|
||||
|
||||
## Related links
|
||||
|
||||
|
|
|
|||
|
|
@ -105,14 +105,21 @@ Using SQS FIFO (`fifo` metadata field set to `"true"`) per AWS specifications pr
|
|||
|
||||
Specifying `fifoMessageGroupID` limits the number of concurrent consumers of the FIFO queue used to only one but guarantees global ordering of messages published by the app's Dapr sidecars. See [this AWS blog post](https://aws.amazon.com/blogs/compute/solving-complex-ordering-challenges-with-amazon-sqs-fifo-queues/) to better understand the topic of Message Group IDs and FIFO queues.
|
||||
|
||||
To avoid losing the order of messages delivered to consumers, the FIFO configuration for the SQS Component requires the `concurrencyMode` metadata field set to `"single"`.
|
||||
|
||||
#### Default parallel `concurrencyMode`
|
||||
|
||||
Since v1.8.0, the component supports the `"parallel"` `concurrencyMode` as its default mode. In prior versions, the component default behavior was calling the subscriber a single message at a time and waiting for its response.
|
||||
|
||||
#### SQS dead-letter Queues
|
||||
|
||||
When configuring the PubSub component with SQS dead-letter queues, the metadata fields `messageReceiveLimit` and `sqsDeadLettersQueueName` must both be set to a value. For `messageReceiveLimit`, the value must be greater than `0` and the `sqsDeadLettersQueueName` must not be empty string.
|
||||
|
||||
{{% alert title="Important" color="warning" %}}
|
||||
When running the Dapr sidecar (`daprd`) with your application on EKS (AWS Kubernetes) node/pod already attached to an IAM policy defining access to AWS resources, you **must not** provide AWS access-key, secret-key, and tokens in the definition of the component spec.
|
||||
{{% /alert %}}
|
||||
|
||||
|
||||
## Create an SNS/SQS instance
|
||||
|
||||
{{< tabs "Self-Hosted" "Kubernetes" "AWS" >}}
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ spec:
|
|||
value: false
|
||||
- name: rateLimit
|
||||
value: 1024
|
||||
- name: hearbeat
|
||||
- name: heartbeat
|
||||
value: 15s
|
||||
- name: ackPolicy
|
||||
value: explicit
|
||||
|
|
@ -98,7 +98,7 @@ spec:
|
|||
| replicas | N | [Replicas] | `3` |
|
||||
| memoryStorage | N | [Memory Storage] | `false` |
|
||||
| rateLimit | N | [Rate Limit] | `1024` |
|
||||
| hearbeat | N | [Hearbeat] | `10s` |
|
||||
| heartbeat | N | [Heartbeat] | `10s` |
|
||||
| ackPolicy | N | [Ack Policy] | `explicit` |
|
||||
| deliverPolicy | N | One of: all, last, new, sequence, time | `all` |
|
||||
| domain | N | [JetStream Leafondes] | `HUB` |
|
||||
|
|
@ -166,7 +166,7 @@ nats -s localhost:4222 stream add myStream --subjects mySubject
|
|||
[Replicas]: https://docs.nats.io/jetstream/concepts/consumers#replicas
|
||||
[Memory Storage]: https://docs.nats.io/jetstream/concepts/consumers#memorystorage
|
||||
[Rate Limit]: https://docs.nats.io/jetstream/concepts/consumers#ratelimit
|
||||
[Hearbeat]: https://docs.nats.io/jetstream/concepts/consumers#hearbeat
|
||||
[Heartbeat]: https://docs.nats.io/jetstream/concepts/consumers#heartbeat
|
||||
[Ack Policy]: https://docs.nats.io/nats-concepts/jetstream/consumers#ackpolicy
|
||||
[JetStream Leafonodes]: https://docs.nats.io/running-a-nats-service/configuration/leafnodes/jetstream_leafnodes
|
||||
[Decentralized JWT Authentication/Authorization]: https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/jwt
|
||||
|
|
|
|||
|
|
@ -96,9 +96,9 @@
|
|||
output: true
|
||||
- component: Redis
|
||||
link: redis
|
||||
state: Beta
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.7"
|
||||
since: "1.9"
|
||||
features:
|
||||
input: false
|
||||
output: true
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
- component: AWS SNS/SQS
|
||||
link: setup-aws-snssqs
|
||||
state: Beta
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.6"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
|
|
|
|||
|
|
@ -3,8 +3,14 @@
|
|||
state: Stable
|
||||
version: v1
|
||||
since: "1.8"
|
||||
features:
|
||||
bulkPublish: true
|
||||
bulkSubscribe: false
|
||||
- component: Azure Service Bus
|
||||
link: setup-azure-servicebus
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.0"
|
||||
features:
|
||||
bulkPublish: true
|
||||
bulkSubscribe: true
|
||||
|
|
|
|||
|
|
@ -3,3 +3,6 @@
|
|||
state: Alpha
|
||||
version: v1
|
||||
since: "1.0"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
|
|
|
|||
|
|
@ -3,53 +3,86 @@
|
|||
state: Deprecated
|
||||
version: v1
|
||||
since: "1.9"
|
||||
- component: In Memory
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: In-memory
|
||||
link: setup-inmemory
|
||||
state: Beta
|
||||
version: v1
|
||||
since: "1.7"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: Apache Kafka
|
||||
link: setup-apache-kafka
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.5"
|
||||
features:
|
||||
bulkPublish: true
|
||||
bulkSubscribe: true
|
||||
- component: Redis Streams
|
||||
link: setup-redis-pubsub
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.0"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: JetStream
|
||||
link: setup-jetstream
|
||||
state: Alpha
|
||||
version: v1
|
||||
since: "1.4"
|
||||
- component: Pulsar
|
||||
link: setup-pulsar
|
||||
state: Beta
|
||||
version: v1
|
||||
since: "1.7"
|
||||
since: "1.10"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: Pulsar
|
||||
link: setup-pulsar
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.10"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: MQTT3
|
||||
link: setup-mqtt3
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.7"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: NATS Streaming
|
||||
link: setup-nats-streaming
|
||||
state: Beta
|
||||
version: v1
|
||||
since: "1.0"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: RabbitMQ
|
||||
link: setup-rabbitmq
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.7"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: RocketMQ
|
||||
link: setup-rocketmq
|
||||
state: Alpha
|
||||
version: v1
|
||||
since: "1.8"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
- component: Solace-AMQP
|
||||
link: setup-solace-amqp
|
||||
state: Alpha
|
||||
state: Beta
|
||||
version: v1
|
||||
since: "1.10"
|
||||
features:
|
||||
bulkPublish: false
|
||||
bulkSubscribe: false
|
||||
|
|
|
|||
|
|
@ -33,9 +33,9 @@
|
|||
query: false
|
||||
- component: Azure Table Storage
|
||||
link: setup-azure-tablestorage
|
||||
state: Beta
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.7"
|
||||
since: "1.9"
|
||||
features:
|
||||
crud: true
|
||||
transactions: false
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@
|
|||
query: false
|
||||
- component: CockroachDB
|
||||
link: setup-cockroachdb
|
||||
state: Beta
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.7"
|
||||
since: "1.10"
|
||||
features:
|
||||
crud: true
|
||||
transactions: true
|
||||
|
|
@ -64,7 +64,7 @@
|
|||
etag: false
|
||||
ttl: false
|
||||
query: false
|
||||
- component: In Memory
|
||||
- component: In-memory
|
||||
link: setup-inmemory
|
||||
state: Developer-only
|
||||
version: v1
|
||||
|
|
@ -110,9 +110,9 @@
|
|||
query: true
|
||||
- component: MySQL
|
||||
link: setup-mysql
|
||||
state: Beta
|
||||
state: Stable
|
||||
version: v1
|
||||
since: "1.7"
|
||||
since: "1.10"
|
||||
features:
|
||||
crud: true
|
||||
transactions: true
|
||||
|
|
|
|||
|
|
@ -10,6 +10,8 @@
|
|||
<table width="100%">
|
||||
<tr>
|
||||
<th>Component</th>
|
||||
<th>Bulk Publish</th>
|
||||
<th>Bulk Subscribe</th>
|
||||
<th>Status</th>
|
||||
<th>Component version</th>
|
||||
<th>Since runtime version</th>
|
||||
|
|
@ -18,6 +20,8 @@
|
|||
<tr>
|
||||
<td><a href="/reference/components-reference/supported-pubsub/{{ .link }}/">{{ .component }}</a>
|
||||
</td>
|
||||
<td align="center">{{ if .features.bulkPublish }}✅{{else}}<img src="/images/emptybox.png">{{ end }}</td>
|
||||
<td align="center">{{ if .features.bulkSubscribe }}✅{{else}}<img src="/images/emptybox.png">{{ end }}</td>
|
||||
<td>{{ .state }}</td>
|
||||
<td>{{ .version }}</td>
|
||||
<td>{{ .since }}</td>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -1 +1 @@
|
|||
Subproject commit e87b9ad6eefaa05390144d82642df13c5b4bed17
|
||||
Subproject commit 52b82d7ce6599822a37d2528379f5ca146e286bb
|
||||
Loading…
Reference in New Issue