Azure service bus queue Message deadlettered after Message.Abandon

Question

I am trying out Azure Service Bus queue. I have the below code:

Queue send:

string strConnectionString = ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"];
        var namespaceManager = NamespaceManager.CreateFromConnectionString(strConnectionString);
        if (!namespaceManager.QueueExists("Test"))
        {
            QueueDescription qD = new QueueDescription("Test");
            qD.DefaultMessageTimeToLive = new TimeSpan(05, 00, 00);
            qD.LockDuration = new TimeSpan(00, 02, 30);
            qD.MaxSizeInMegabytes = 5120;                
            namespaceManager.CreateQueue(qD);              
        }
        if (namespaceManager.QueueExists("Test"))
        {
            QueueClient client = QueueClient.CreateFromConnectionString(strConnectionString, "Test", ReceiveMode.PeekLock);
            var qMessage = Console.ReadLine();
            using (MemoryStream strm = new MemoryStream(Encoding.UTF8.GetBytes(qMessage)))
            {
                BrokeredMessage bMsg = new BrokeredMessage(strm);
                bMsg.MessageId = Guid.NewGuid().ToString();
                bMsg.TimeToLive = new TimeSpan(05, 00, 00);
                client.Send(bMsg);
                Console.WriteLine("Message sent");
            }
        }
        Console.ReadLine();

The receive code:

 string strConnectionString = ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"];
        var namespaceManager = NamespaceManager.CreateFromConnectionString(strConnectionString);
        if (namespaceManager.QueueExists("Test"))
        {
            QueueClient client = QueueClient.CreateFromConnectionString(strConnectionString, "Test",ReceiveMode.PeekLock);
            if (client != null)
            {
                OnMessageOptions options = new OnMessageOptions();
                options.AutoComplete = false;
                options.AutoRenewTimeout = TimeSpan.FromSeconds(31);                 


                client.OnMessage((message) =>
                    {                           
                        Console.WriteLine(message.State.ToString());
                        Console.WriteLine("Message Id: " + message.MessageId);
                        Stream stream = message.GetBody<Stream>();
                        StreamReader reader = new StreamReader(stream);
                        Console.WriteLine("Message: " + reader.ReadToEnd());                                
                        Console.WriteLine("***************");
                        message.Abandon();
                    });
                Console.ReadLine();
            }
        }

I see that whenever I call Abandon, the message is getting DeadLettered. My assumption was that it should get Active and can be picked up by another client.

Answer 1

Your understanding of BrokeredMessage.Abandon Api is correct. It is intended to abandon the peek-lock acquired on the message (but NOT abandon the message itself) and hence, makes it available for other receivers to pick the Message up.

Here's how we envisioned different states of a peek-lock'ed message:

Basics first

The 'Why': If Customers need Competing-Consumer (Job-Queue) semantics - where they need multiple workers to simultaneously process different messages from a Queue with Exactly-Once guarantee - then they use the ReceiveMode.PeekLock. In this model, each worker (the queue receiver) needs a way to communicate the Progress of its Current message (Job) to other workers. Hence, brokeredMessage provides 4 functions to express the states.

The 'What':

• if a message is successfully processed by the current Worker - call BrokeredMessage.Complete()
• if the BrokeredMessage cannot be processed by the current worker, and want the processing to be retried on another Worker - then, Abandon the message. But, the catch here is: lets say, there are 2 workers and each of them thinks that the other one can process this message and calls Abandon - soon they will end up in an Infinite loop of retry'ing to process just that message! So, to avoid this situation, we provided a Configuration called MaxDeliveryCount on QueueDescription. This setting guards the limit on the number of times the message is delivered from the Queue to receiver. In the above example, Each time you received (and abandoned) the message, the 'deliveryCount' on the ServiceBus service is incremented. When it reaches 10 - the message has hit max no. of deliveries and hence, will be deadlettered.
• if the current receiver (worker) knows for sure, that, this message cannot be processed, BrokeredMessage.DeadLetter(). The goal here is to let the consuming application Audit the dead-lettered messages regularly.
• if the current receiver (worker) cannot process this message, but, knows that this message can be processed at a later point of time BrokeredMessage.Defer().

HTH! Sree