You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<1> `--channel` specifies the source for cloud events that should be processed. You must provide the channel name. If you are not using the default `InMemoryChannel` channel that is backed by the `Channel` resource, you must prefix the channel name with the `<group:version:kind>` for the specified channel type. For example, this will be `messaging.knative.dev:v1beta1:KafkaChannel` for a Kafka backed channel.
30
+
<2> `--sink` specifies the target destination to which the event should be delivered. By default, the `<sink_name>` is interpreted as a Knative service of this name, in the same namespace as the subscription. You can specify the type of the sink by using one of the following prefixes:
31
+
`ksvc`:: A Knative service.
32
+
`channel`:: A channel that should be used as destination. Only default channel types can be referenced here.
33
+
`broker`:: An Eventing broker.
34
+
<3> Optional: `--sink-dead-letter` is an optional flag that can be used to specify a sink which events should be sent to in cases where events fail to be delivered. For more information, see the {ServerlessProductName} _Event delivery_ documentation.
= Event delivery behavior for Knative Eventing channels
7
+
8
+
Different Knative Eventing channel types have their own behavior patterns that are followed for event delivery. Developers can set event delivery parameters in the subscription configuration to ensure that any events that fail to be delivered from channels to an event sink are retried. You must also configure a dead letter sink for subscriptions if you want to provide a sink where events that are not eventually delivered can be stored, otherwise undelivered events are dropped.
9
+
10
+
== Event delivery behavior for Apache Kafka channels
11
+
12
+
If an event is successfully delivered to a Kafka channel or broker receiver, the receiver responds with a `202` status code, which means that the event has been safely stored inside a Kafka topic and is not lost. If the receiver responds with any other status code, the event is not safely stored, and steps must be taken by the user to resolve this issue.
13
+
14
+
== Delivery failure status codes
15
+
16
+
The channel or broker receiver can respond with the following status codes if an event fails to be delivered:
17
+
18
+
`500`:: This is a generic status code which means that the event was not delivered successfully.
19
+
`404`:: This status code means that the channel or broker the event is being delivered to does not exist, or that the `Host` header is incorrect.
20
+
`400`:: This status code means that the event being sent to the receiver is invalid.
= Configuring event delivery failure parameters using subscriptions
7
+
8
+
Developers can configure event delivery parameters for individual subscriptions by modifying the `delivery` settings for a `Subscription` object.
9
+
10
+
.Example subscription YAML
11
+
[source,yaml]
12
+
----
13
+
apiVersion: messaging.knative.dev/v1
14
+
kind: Subscription
15
+
metadata:
16
+
name: <subscription_name>
17
+
namespace: <subscription_namespace>
18
+
spec:
19
+
delivery:
20
+
deadLetterSink: <1>
21
+
ref:
22
+
apiVersion: serving.knative.dev/v1
23
+
kind: Service
24
+
name: <sink_name>
25
+
backoffDelay: <duration> <2>
26
+
backoffPolicy: <policy_type> <3>
27
+
retry: <integer> <4>
28
+
----
29
+
<1> Configuration settings to enable using a dead letter sink. This tells the subscription what happens to events that cannot be delivered to the subscriber.
30
+
+
31
+
When this is configured, events that fail to be delivered are sent to the dead letter sink destination. The destination can be a Knative service or a URI.
32
+
<2> You can set the `backoffDelay` delivery parameter to specify the time delay before an event delivery retry is attempted after a failure. The duration of the `backoffDelay` parameter is specified using the https://en.wikipedia.org/wiki/ISO_8601#Durations[ISO 8601] format. For example, `PT1S` specifies a 1 second delay.
33
+
<3> The `backoffPolicy` delivery parameter can be used to specify the retry back off policy. The policy can be specified as either `linear` or `exponential`. When using the `linear` back off policy, the back off delay is the time interval specified between retries. When using the `exponential` back off policy, the back off delay is equal to `backoffDelay*2^<numberOfRetries>`.
34
+
<4> The number of times that event delivery is retried before the event is sent to the dead letter sink.
You can update a subscription by using the `kn` CLI.
9
+
10
+
.Prerequisites
11
+
12
+
To update subscriptions using the `kn` CLI, ensure that:
13
+
14
+
* The {ServerlessOperatorName} and Knative Eventing are installed on your {product-title} cluster.
15
+
* You have installed the `kn` CLI.
16
+
* You have access to a project with the appropriate roles and permissions to create applications and other workloads in {product-title}.
17
+
* You have created a subscription.
18
+
19
+
.Procedure
20
+
21
+
* Update a subscription:
22
+
+
23
+
[source,terminal]
24
+
----
25
+
$ kn subscription update <subscription_name> \
26
+
--sink <sink_prefix>:<sink_name> \ <1>
27
+
--sink-dead-letter <sink_prefix>:<sink_name> <2>
28
+
----
29
+
<1> `--sink` specifies the updated target destination to which the event should be delivered. You can specify the type of the sink by using one of the following prefixes:
30
+
`ksvc`:: A Knative service.
31
+
`channel`:: A channel that should be used as destination. Only default channel types can be referenced here.
32
+
`broker`:: An Eventing broker.
33
+
<2> Optional: `--sink-dead-letter` is an optional flag that can be used to specify a sink which events should be sent to in cases where events fail to be delivered. For more information, see the {ServerlessProductName} _Event delivery_ documentation.
* After you have created a channel, see xref:../../serverless/event_workflows/serverless-subs.adoc#serverless-subs[Using subscriptions] for information about creating and using subscriptions for event delivery.
You can configure event delivery parameters for Knative Eventing that are applied in cases where an event fails to be delivered by a xref:../../serverless/event_workflows/serverless-subs.adoc#serverless-subs[subscription]. Event delivery parameters are configured individually per subscription.
10
+
// TODO: Update docs to add triggers once this is implemented.
The following parameters can be configured for event delivery.
18
+
19
+
Dead letter sink:: You can configure the `deadLetterSink` delivery parameter so that if an event fails to be delivered it is sent to the specified event sink.
20
+
21
+
Retries:: You can set a minimum number of times that the delivery must be retried before the event is sent to the dead letter sink, by configuring the `retry` delivery parameter with an integer value.
22
+
23
+
Back off delay:: You can set the `backoffDelay` delivery parameter to specify the time delay before an event delivery retry is attempted after a failure. The duration of the `backoffDelay` parameter is specified using the https://en.wikipedia.org/wiki/ISO_8601#Durations[ISO 8601] format.
24
+
25
+
Back off policy:: The `backoffPolicy` delivery parameter can be used to specify the retry back off policy. The policy can be specified as either `linear` or `exponential`. When using the `linear` back off policy, the back off delay is the time interval specified between retries. When using the `exponential` backoff policy, the back off delay is equal to `backoffDelay*2^<numberOfRetries>`.
* See xref:../../serverless/event_workflows/serverless-channels.adoc#serverless-channels[Knative Eventing workflows using channels] for more information about subscriptions.
33
+
* See xref:../../serverless/event_workflows/serverless-subs.adoc#serverless-subs-creating-subs[Creating subscriptions].
0 commit comments