Event delivery

Overview

Knative Eventing provides various configuration parameters to control the delivery of events in case of failure. For instance, you can decide to retry sending events that failed to be consumed, and if this didn’t work you can decide to forward those events to a dead letter sink.

Configuring Subscription Delivery

Knative Eventing offers fine-grained control on how events are delivered for each subscription by adding a delivery section. Consider this example:

  1. apiVersion: messaging.knative.dev/v1
  2. kind: Subscription
  3. metadata:
  4.   name: with-dead-letter-sink
  5. spec:
  6.   channel:
  7.     apiVersion: messaging.knative.dev/v1
  8.     kind: InMemoryChannel
  9.     name: default
  10.   delivery:
  11.     deadLetterSink:
  12.       ref:
  13.         apiVersion: serving.knative.dev/v1
  14.         kind: Service
  15.         name: error-handler
  16.   subscriber:
  17.     uri: http://doesnotexist.default.svc.cluster.local

The deadLetterSink specifies where to send events that failed be consumed by subscriber.

Configuring Broker Delivery

Knative Eventing offers fine-grained control on how events are delivered for each broker by adding a delivery section. Consider this example:

  1. apiVersion: messaging.knative.dev/v1
  2. kind: Subscription
  3. metadata:
  4.   name: with-dead-letter-sink
  5. spec:
  6.   channel:
  7.     apiVersion: messaging.knative.dev/v1
  8.     kind: InMemoryChannel
  9.     name: default
  10.   delivery:
  11.     retry: 5
  12.     backoffPolicy: exponential # or linear
  13.     backoffDelay: "PT0.5S"     # or ISO8601 duration
  14.     deadLetterSink:
  15.       ref:
  16.         apiVersion: serving.knative.dev/v1
  17.         kind: Service
  18.         name: error-handler
  19.   subscriber:
  20.     uri: http://doesnotexist.default.svc.cluster.local

The Broker will retry sending events 5 times with a backoff delay of 500 milliseconds and exponential backoff policy.

The deadLetterSink specifies where to send events that failed to be consumed by subscriber after the specified number of retries.

Common Delivery Parameters

The delivery value must be a Delivery Spec

deadLetterSink

When present, events that failed to be consumed are sent to the deadLetterSink. In case of failure, the event is dropped and an error is logged into the system.

The deadLetterSink value must be a Destination.

  1. spec:
  2.   delivery:
  3.     deadLetterSink: <Destination>
  4.     retry: <number of retries>
  5.     backoffPolicy: <linear or exponential>
  6.     backoffDelay: <ISO8601 duration>

Channel Support

The table below summarizes what delivery parameters are supported for each channel implementation.

Channel TypeSupported Delivery Parameters
GCP PubSubnone
In-MemorydeadLetterSink, retry, backoffPolicy, backoffDelay
KafkadeadLetterSink, retry, backoffPolicy, backoffDelay
Natssnone

Broker Support

The table below summarizes what delivery parameters are supported for each Broker implementation.

Broker ClassSupported Delivery Parameters
googleclouddeadLetterSink 1, retry, backoffPolicy, backoffDelay 2
KafkadeadLetterSink, retry, backoffPolicy, backoffDelay
MTChannelBasedBrokerdepends on the underlying channel
RabbitMQBrokerdeadLetterSink, retry, backoffPolicy, backoffDelay

  1. deadLetterSink must be a GCP Pub/Sub topic uri:

    1. deadLetterSink:
    2.   uri: pubsub://dead-letter-topic

    Please see the config-br-delivery ConfigMap for a complete example. ↩︎

  2. The googlecloud broker only supports the exponential backoffPolicy. ↩︎

Feedback

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.