CRUD Operations with Azure Queue Storage in an Azure Function – Retrieve

In the previous blog post, we explored how to Enqueue and Dequeue items from Azure Storage. Let us continue our exploration of Queue storage and write code to “peek” from a queue.

Peek/Retrieve From Queue

For retrieve from Queue, you could use the CloudQueue.PeekMessageAsync() method. For example,

[FunctionName("PeekItemFromQueue")]
public static async Task<IActionResult> PeekItemFromQueue(
[HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = null)] HttpRequest request,
[Queue("SampleQueue")] CloudQueue cloudQueue)
{

    var message = await cloudQueue.PeekMessageAsync();
    

    if (message == null)
        return new OkObjectResult("No item in the queue");

    var resultBuilder = new StringBuilder();
    resultBuilder.AppendLine($"Message : `({message.AsString})`");
    resultBuilder.AppendLine($"Pop Reciept : {message.PopReceipt}");
    resultBuilder.AppendLine($"Dequeue Count : {message.DequeueCount}");
    resultBuilder.AppendLine($"Insertion Time: {message.InsertionTime}");
    resultBuilder.AppendLine($"Next Visible Time: {message.NextVisibleTime}");
    return new OkObjectResult(resultBuilder.ToString());
}

The CloudMessageQueue object provides some interesting properties about the retrieved message. For example, the above query could provide following details.

Message : `SampleMessageForTest`
Pop Reciept : 
Dequeue Count : 0
Insertion Time: 17-04-2021 02:38:55 +00:00
Next Visible Time:

The DequeueCount property specifies the number of times the message has been retrieved without being deleted from the queue. Remember, when a message is retrieved from the Azure Queue, it is not removed from the Queue. The DequeueCount property hints at the number of attempts to retrieve the message by client applications.

While the message is not removed from the Queue entirely, it does disappears from the queue for a designated time. The Next Visible Time indicates the time at which the message would appear back once is has disappeared temperarly.

You could also in effect use the CloudQueue.GetMessageAsync method as well, since by default the mesage is not removed from the original queue. However, the difference lies in the fact that the GetMessageAsync method would remove the message from queue temporarly, and increment the DequeueCount. It would also issue a PopReciept. But that’s not the case with PeekMessageAsync, which would not hide the message from the queue nor would be increment the DequeueCount. Following would be the response if we had used GetMessageAsync instead of PeekMessageAsync.

Message : `SampleMessageForTest`
Pop Reciept : cIGyxZkB2QgBAAAA
Dequeue Count : 1
Insertion Time: 17-04-2021 02:38:55 +00:00
Next Visible Time: 17-04-2021 12:10:20 +00:00

A Word about Poison Queue

There could be situations wherein the message in the queue appear as a clog in the system as the message could retried too many times. As a guard against this, the concept was poison queue was introduced. Any message that has been retried over 5 times, is considered as poison message (could harm the application), are moved to different queue called the Poison Queue, usually named as queuename-poison.

Since you know the name of the poison queue, you could still process the messages in the queue. Depending on your application/business needs you can decide on the stratergy to process the poison queue messages. Irrespective of your business needs, one of the important point to consider when processing the poison messages is attempting to understand the reason why the message was moved to poison queue in first place.

That’s all for now. We will continue exploring the Azure Storage with this byte sized tutorial series.