You can configure event delivery parameters for Knative Eventing that are applied in cases where an event fails to be delivered by a subscription or trigger to a subscriber. Event delivery parameters are configured individually per subscriber.
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.
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.
The channel or broker receiver can respond with the following status codes if an event fails to be delivered:
500This is a generic status code which means that the event was not delivered successfully.
404This status code means that the channel or broker the event is being delivered to does not exist, or that the Host header is incorrect.
400This status code means that the event being sent to the receiver is invalid.
Knative Eventing provides configuration parameters that can be used to control what happens to events in cases where events fail to be delivered. For example, you can configure Knative to retry sending events that failed to be consumed, or forward these events to a dead letter sink.
The following parameters can be configured for event delivery:
You can configure the deadLetterSink delivery parameter so that if an event fails to be delivered it is sent to the specified event sink.
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.
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 ISO 8601 format.
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>.
After you have created a channel and an event sink, you can create a subscription to enable event delivery. You can configure event delivery parameters for individual subscriptions by modifying the delivery settings for a Subscription object. Knative Eventing provides configuration parameters for subscriptions that you can use to control what happens to events in cases where events fail to be delivered.
Subscription objectapiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
name: <subscription_name>
namespace: <subscription_namespace>
spec:
delivery:
deadLetterSink: (1)
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: <sink_name>
backoffDelay: <duration> (2)
backoffPolicy: <policy_type> (3)
retry: <integer> (4)| 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.
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. |
| 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 ISO 8601 format. For example, PT1S specifies a 1 second delay. |
| 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>. |
| 4 | The number of times that event delivery is retried before the event is sent to the dead letter sink. |