Azure Service bus Queue Size & Topic Size

Question

I want understand the following points regarding the azure service bus more. Need inputs on this.

In Azure Service Bus

1. Queue Size/Topic Size = Active Messages + Dead Letter Messages + Forward To/Transfer Messages (until they are forwarded) + Scheduled Messages + Transfer Dead letter

2. What will happen if a message is sent to queue/topic after it reaches the maximum size?

3. I have configured a Forward to on a subscription(With True Filter) to an another topic and made the topic inactive. When I sent a message on to the topic, since the Forward Topic is not active it has to increase the Transfer Dead Letter Message count ( as per Microsoft Doc https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-counters) but instead it is increasing the Dead Letter Message count.

4.What are the scenarios when filters on subscriptions evaluation failed?

Answer 1

1.The behavior when a message is sent to a queue or topic and surpasses the maximum size relies on the settings and configurations of the queue/topic.

For queues:

When a message expires, it may be transferred to the dead-letter queue if the queue's "EnableDeadLetteringOnMessageExpiration" property is set to true. When a filter evaluation exception occurs, if the queue's "EnableDeadLetteringOnFilterEvaluationExceptions" property is set to true, the message will be redirected to the dead-letter queue.

For topics:

• If the topic has the "EnableDeadLetteringOnMessageExpiration" property set to true, the message will be moved to the dead-letter queue of the topic when it expires.

• If the topic has the "EnableDeadLetteringOnFilterEvaluationExceptions" property set to true, the message will be moved to the dead-letter queue if there is a filter evaluation exception.

• • using PeekLock we can move the messages queue From this MSDOC.

QueueClient queueClient = new QueueClient(connectionString, queueName);
            MessageReceiver messageReceiver = new MessageReceiver(connectionString, queueName, ReceiveMode.PeekLock);
            while (true)
            {
                Message message = await messageReceiver.ReceiveAsync();
                  if (message == null || message.Body == null || message.Body.Length == 0)
                {
                    break;
                }
              string messageContent = Encoding.UTF8.GetString(message.Body);  
          if((messageContent.Contains(itemToRemove)))
                {
                  await messageReceiver.AbandonAsync(message.SystemProperties.LockToken);
               
    log.LogInformation($"Item {itemToRemove}' not found in message with ID '{message.MessageId}' ");         
                }
            }

            await queueClient.CloseAsync();
            await messageReceiver.CloseAsync();

2. The behaviour should be as follows in your scenario, where you have configured a Forward To on a subscription with a true filter to another topic that is inactive: The message won't be forwarded and will remain in the original subject if the forward destination topic is dormant. In this situation, the number of Transfer Dead Letter Messages shouldn't rise. If you see that the Transfer Dead Letter Message count is down but the Dead Letter Message count is rising, this may be a sign of a configuration error or unanticipated behaviour. whether this behaviour persists, you could wish to double-check your subscription settings and see whether any other variables are at play.

Output:

3.These are some examples of scenarios where filters used for subscriptions evaluation fail: problems in syntax or improper filter expressions. filtering problems where the message's characteristics are not met. use of unsupported filter operators or functions. filter rules that aren't configured correctly.

Output:

4. When a filter evaluation fails, the message may not be delivered to the subscription or may be moved to the dead-letter queue, depending on the subscription's settings. It's important to ensure that the filter expressions are correctly defined and match the expected message properties to avoid filter evaluation failures .

For more details Refer these links:

• Service Bus dead letter queues

• Message Expiration