Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Azure service bus - message going straight to dead letter queue

I have the following code to send messages to the bus:

var queueClient = new QueueClient(ServiceBusConnectionString, QueueName);

var message = new Message(poco.SerializeToBytes());

await queueClient.SendAsync(message);

But they seem to be going straight into the DEAD-LETTER MESSAGE COUNT:

enter image description here

I have also created an Azure function which will pick messages up:

    [FunctionName("ServiceBusFunction")]
    public static void Run([ServiceBusTrigger("schedule", AccessRights.Listen, Connection = "ServiceBusConnection")]byte[] myQueueItem, TraceWriter log)
    {
        log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
    }

When I turn the function off, the messages were go into the ACTIVE MESSAGE COUNT before I created this function. I've tried running the function locally and the function was not being hit. I feel like I'm missing something fundamental in terms of picking up messages on the bus from a function?

like image 721
David Masters Avatar asked Mar 01 '18 14:03

David Masters


People also ask

Why are my messages going to dead-letter queue?

The dead-letter queue (or undelivered-message queue) is the queue to which messages are sent if they cannot be routed to their correct destination. Messages are put on this queue when they cannot be put on the destination queue. For example, because the queue does not exist, or because it is full.

How do you handle a dead-letter queue?

Start examining the messages that went to the Dead Letter Queue. Try and re-process the messages to determine the underlying cause of the failure (but sometimes it is a random failure that you cannot reproduce) Once a cause is found, update the system to handle that particular use-case, then move onto the next cause.

Why do AWS messages go to dead-letter queue?

A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. Messages that can't be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing.


1 Answers

If you go to your Function App logs, you'll probably see errors like

Exception binding parameter 'myQueueItem'. Microsoft.Azure.WebJobs.ServiceBus: The BrokeredMessage with ContentType 'null' failed to deserialize to a byte[] with the message: 'There was an error deserializing the object of type System.Byte[]. The input source is not correctly formatted.'. System.Runtime.Serialization: There was an error deserializing the object of type System.Byte[]. The input source is not correctly formatted. System.Runtime.Serialization: The input source is not correctly formatted. 2018-03-01T15:14:41.578

Function App tries to process your message 10 times (default), and then puts it into DLQ with

Message could not be consumed after 10 delivery attempts.

The problem has to do with the fact that you are sending messages from "the new" .NET Standard Service Bus client, while Function App v1 is using "the old" BrokeredMessage-based client. And they are not compatible on binary level, see this issue.

Until Function App v2 including Service Bus binding is ready, you should better use the old Service Bus client to send messages. If you have to use the new client, see some workarounds in the issue linked above, e.g. this comment.

like image 82
Mikhail Shilkov Avatar answered Nov 14 '22 13:11

Mikhail Shilkov