From d78b747361d65246b429ddbab67912da27b28a3d Mon Sep 17 00:00:00 2001 From: Aaron Crawfis Date: Fri, 15 Jan 2021 15:22:21 -0800 Subject: [PATCH] Update order --- .../pubsub/pubsub-message-ttl.md | 28 ++++++++----------- 1 file changed, 11 insertions(+), 17 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md index 9b54a4149..542142512 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md @@ -8,30 +8,24 @@ description: "Use time-to-live in Pub/Sub messages." ## Introduction -Dapr enables per message time-to-live for all Pub/Sub components. It means that applications can set time-to-live per message and subscribers will not receive those messages after expiration. +Dapr enables per-message time-to-live (TTL). This means that applications can set time-to-live per message, and subscribers will not receive those messages after expiration. -In Kafka, time-to-live is configured in the topic via `retention.ms` as per [documentation](https://kafka.apache.org/documentation/#topicconfigs_retention.ms). With message time-to-live in Dapr, applications using Kafka can now set time-to-live per message too, since Dapr will handle the expiration. +All Dapr [pub/sub components]({{< ref supported-pubsub >}}) are compatible with message TTL, as Dapr handles the TTL logic within the runtime. -On the other hand, Azure Service Bus supports [entity level time-to-live]((https://docs.microsoft.com/en-us/azure/service-bus-messaging/message-expiration)). It means that messages have a default time-to-live but can also be set with a shorter timespan at publishing time. Dapr will propagate the time-to-live metadata for the message and let Azure Service Bus handle expiration directly. This is referred as "native support" for message TTL. +In some components, such as Kafka, time-to-live can be configured in the topic via `retention.ms` as per [documentation](https://kafka.apache.org/documentation/#topicconfigs_retention.ms). With message TTL in Dapr, applications using Kafka can now set time-to-live per message in addition to per topic. -### Pub/Sub components with message TTL +## Native message TTL support -* All, some are implemented natively. +When message time-to-live has native support in the component, Dapr will simply forward the time-to-live configuration without adding extra logic, keeping predictable behavior. This is helpful when the expired messages are handled differently by the component - like in Azure Service Bus, where expired messages are stored in the dead letter queue and not simply deleted. -### Subscribers outside Dapr +### Components with native message TTL support -If messages are consumed by subscribers without Dapr, expired messages are not automatically dropped. Still, subscribers can programatically drop expired messages by adding logic to handle the `expiration` attribute in the cloud event. +#### Azure Service Bus -> The `expiration` attribute follows the [RFC3339](https://tools.ietf.org/html/rfc3339) format. +Azure Service Bus supports [entity level time-to-live]((https://docs.microsoft.com/en-us/azure/service-bus-messaging/message-expiration)). It means that messages have a default time-to-live but can also be set with a shorter timespan at publishing time. Dapr will propagate the time-to-live metadata for the message and let Azure Service Bus handle expiration directly. -## Native support for message TTL +## Non-Dapr subscribers -When Message Time-To-Live has native support in the component, Dapr will simply forward the time-to-live configuration without adding extra logic, keeping predictable behavior. This is helpful when the expired messages are handled differently by the component - like in Azure Service Bus, where expired messages are stored in the dead letter queue and not simply deleted. +If messages are consumed by subscribers without Dapr, expired messages are not automatically dropped, as expiration is handled by the Dapr runtime when a Dapr application receives a message. However, subscribers can programmatically drop expired messages by adding logic to handle the `expiration` attribute in the cloud event, which follows the [RFC3339](https://tools.ietf.org/html/rfc3339) format. -### Pub/Sub components with native support for message TTL - -* Azure Service Bus - -### Subscribers outside Dapr - -In this case, subscribers via Dapr or outside Dapr will not receive expired messages. No extra logic is needed. \ No newline at end of file +When non-Dapr subscribers use components such as Azure Service Bus, which natively handle message TTL, they will not receive expired messages. No extra logic is needed. \ No newline at end of file