We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.
You can configure how events are delivered for each broker by adding a
delivery spec, as shown in the following example:
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: name: with-dead-letter-sink spec: delivery: deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: example-sink backoffDelay: <duration> backoffPolicy: <policy-type> retry: <integer>
deadLetterSinkspec contains 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 any Addressable object that conforms to the Knative Eventing sink contract, such as a Knative service, a Kubernetes service, or a URI. In the example, the destination is a
Serviceobject, or Knative service, named
backoffDelaydelivery parameter specifies the time delay before an event delivery retry is attempted after a failure. The duration of the
backoffDelayparameter is specified using the ISO 8601 format. For example,
PT1Sspecifies a 1 second delay.
backoffPolicydelivery parameter can be used to specify the retry back off policy. The policy can be specified as either
exponential. When using the
linearback off policy, the back off delay is the time interval specified between retries. This is a linearly increasing delay, which means that the back off delay increases by the given interval for each retry. When using the
exponentialback off policy, the back off delay increases by a multiplier of the given interval for each retry.
retryspecifies the number of times that event delivery is retried before the event is sent to the dead letter sink. The initial delivery attempt is not included in the retry count, so the total number of delivery attempts is equal to the
The following table summarizes which delivery parameters are supported for each broker implementation type:
|Broker Class||Supported Delivery Parameters|
|MTChannelBasedBroker||depends on the underlying channel|
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.