Proposal to improve eventing/channel/MessageDispatcher #7456
Labels
kind/feature-request
lifecycle/stale
Denotes an issue or PR has remained open with no activity and has become stale.
triage/needs-user-input
Issues which are waiting on a response from the reporter
Problem
There is
knative.dev/eventing
golang library, it haschannel
package. There isMessageDispatcher
inchannel
package. Simplified diagram how it is working:The message dispatcher is used by eventing brokers, like eventing-natss, eventing-kafka (most likely), etc. The problem is in the
MessageDispatcher
, what if dispatcher crashes? The message should be re-delivered by an underlying message queue/stream, for that message re-delivery should be configured on underlying stream consumer, e.g. in Nats/JetStream case there is MaxDeliver property for a consumer. The same time there are retries configured on trigger/subscription level. It is possible that there will be more re-deliveries then configured on trigger level, image message was retried 4 of 5 times and then dispatcher crashes, after restart the message is redelivered by Nats and it is possible it will be retires another 5 times.Another thing is why should a
MessageDispatcher
retry message in-memory if there is a feature on underlying stream consumer likeMaxDeliver
on JetStream?If I'd like to utilize JetStream's retry feature, then I need to totally re-implement
MessageDispatcher
because I do not want to lose DLQ and replyUrl functionality.Persona:
Contributor/Corporate (employed) maintainer
Exit Criteria
MessageDispatcher
has pluggable version ofDispatchMessageWithRetries
so that it is possible to identify if there are no retries on underlying stream consumer side.Additional context (optional)
Related PR knative-extensions/eventing-natss#426
The text was updated successfully, but these errors were encountered: