Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DLQ for Sink #1660

Closed
10 tasks done
vigith opened this issue Apr 12, 2024 · 2 comments · Fixed by #1691
Closed
10 tasks done

DLQ for Sink #1660

vigith opened this issue Apr 12, 2024 · 2 comments · Fixed by #1691
Assignees
Labels
area/sink enhancement New feature or request
Milestone

Comments

@vigith
Copy link
Member

vigith commented Apr 12, 2024

Problem

DLQ is already available out-of-the-box in Numaflow (using conditional forwarding) except for the Sink vertex. In the Sink vertex, the user must "manually" write to a DLQ if the Sink is down; otherwise, the backpressure caused will back-propagate and stop reading from the source. This is a significant concern when users have multiple Sinks where they expect writes to happen even if there is a failing Sink (else a failing Sink can cause the entire pipeline to stall).

Approaches

Multiple Container for fallback

e.g.,

    - name: out
      sink:
        # A simple log printing sink
        log: {}
        fallback:
          - foo
    - name: kafka-out
      sink:
        udsink:
          container:
            image: my-sink:latest
        fallback:
          kafka:
            brokers:
              - my-broker1:19700
              - my-broker2:19700
            topic: my-topic

Conditional Forwarding at Sink level

DLQ is unavailable only in the Sink because it is a terminal state, and no forwarding happens after the Sink. We could extend the conditional-forwarding and let a Sink forward to another Sink.

Use Cases

  • Write to a different Sink if the current Sink is failing
    • e.g., Write to Kafka if the Database Sink is under maintenance.
  • DLQ Sink can be connected back to Source and call a DLQ source, and the same messages can be fed in (solved problem via multi-source)

Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

Core

Preview Give feedback
  1. area/sink
    yhl25
  2. testing

SDK

Preview Give feedback
  1. enhancement
    kohlisid
@vigith vigith added enhancement New feature or request area/sink labels Apr 12, 2024
@vigith vigith added this to the 1.2 milestone Apr 13, 2024
@whynowy
Copy link
Member

whynowy commented Apr 13, 2024

@yhl25 - be aware we need to have a different sock file and server-info file for the fallback container.

@whynowy
Copy link
Member

whynowy commented Apr 13, 2024

@yhl25 - be aware we need to have a different sock file and server-info file for the fallback container.

We can populate a builtin ENV for all the UD containers to indicate the container type.

@yhl25 yhl25 closed this as completed Apr 19, 2024
@yhl25 yhl25 reopened this Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/sink enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants