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

On UnknownHostException never send messages to DLQ #130

Open
lorenzoponsb opened this issue Nov 25, 2024 · 2 comments
Open

On UnknownHostException never send messages to DLQ #130

lorenzoponsb opened this issue Nov 25, 2024 · 2 comments

Comments

@lorenzoponsb
Copy link

When the connector loses the connection with Kusto, it never sends the messages to the DLQ.

I think the reason is that it only throws an exception if the KustoSinkConfig.BehaviorOnError.FAIL is activated:
https://github.com/Azure/kafka-sink-azure-kusto/blob/master/src/main/java/com/microsoft/azure/kusto/kafka/connect/sink/FileWriter.java#L196

But for the message to be inserted into the DLQ, it has to be different than BehaviorOnError.FAIL:
https://github.com/Azure/kafka-sink-azure-kusto/blob/master/src/main/java/com/microsoft/azure/kusto/kafka/connect/sink/TopicPartitionWriter.java#L170

@ag-ramachandran
Copy link
Contributor

hello @lorenzoponsb

I think this was by design.

Reason was the following:

The DLQ was set up for errors like deserialization, one message cannot hold processing of all messages in the topic. So make it into bytes and move it out for analysis

In the case of errors like connectivity not being established, the connector will not process any offset (no messages will go through and hence the offset processed will not move for any message)
In summary, the idea of DLQ was to target specific message that was a bad message as opposed to infra level failures where all messages have to be moved to DLQ

@lorenzoponsb
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants