Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 8. Event delivery
You can configure event delivery parameters to handle cases where delivery to an event sink fails. Each channel and broker type follows its own event delivery behavior.
Configure event delivery parameters, including a dead letter sink, to retry failed events. If you do not configure these parameters, the system drops undelivered events.
8.1. Configurable event delivery parameters Link kopierenLink in die Zwischenablage kopiert!
You can configure the following parameters for event delivery:
If an event is successfully delivered to a channel or broker receiver for Apache Kafka, 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 the issue.
- Dead letter sink
-
You can configure the
deadLetterSinkdelivery parameter to store events that fail delivery in the specified event sink. The system drops undelivered events that are not stored in a dead letter sink. The dead letter sink can be any addressable object that conforms to the Knative Eventing sink contract, such as a Knative service, a Kubernetes service, or a URI. - Retries
- You can configure the retry delivery parameter with an integer value to set the minimum number of delivery attempts before the system sends the event to the dead letter sink.
- Back off delay
-
You can set the
backoffDelaydelivery parameter to specify the delay before the system retries event delivery after a failure. Specify thebackoffDelayvalue by using theISO 8601duration format. For example,PT1Sspecifies a delay of1second. - Back off policy
-
You can use the
backoffPolicydelivery parameter to specify the retry backoff policy. Specify the policy as eitherlinearorexponential. With thelinearpolicy, the system calculates the backoff delay asbackoffDelay * <numberOfRetries>. With theexponentialpolicy, the system calculates the backoff delay asbackoffDelay * 2^<numberOfRetries>.
8.2. Examples of configuring event delivery parameters Link kopierenLink in die Zwischenablage kopiert!
You can configure event delivery parameters for Broker, Trigger, Channel, and Subscription objects. If you configure event delivery parameters for a broker or channel, these parameters propagates to triggers or subscriptions created for those objects. You can also set event delivery parameters for triggers or subscriptions to override the settings for the broker or channel.
The following example displayes Broker object:
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
# ...
spec:
delivery:
deadLetterSink:
ref:
apiVersion: eventing.knative.dev/v1alpha1
kind: KafkaSink
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
# ...
The following example displayes Trigger object:
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
# ...
spec:
broker: <broker_name>
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
# ...
The following example displayes Channel object:
apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
# ...
spec:
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
# ...
The following example displayes Subscription object:
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
# ...
spec:
channel:
apiVersion: messaging.knative.dev/v1
kind: Channel
name: <channel_name>
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
# ...