1
votes

I have 1 Topic with 1 Subscription.

I'm creating messages like this:

BrokeredMessage messageTaskA = new BrokeredMessage("New Task");
messageTaskA.Properties["Type"] = "A";

BrokeredMessage messageTaskB = new BrokeredMessage("New Task");
messageTaskB.Properties["Type"] = "B";

I would like to have the total messages, total messages of type A, total message of type B counters:

1) Total of messages in the Subscription: SubscriptionDescription desc = namespaceManager.GetSubscription("topicName", "subscriptionName"); totalTask = desc.MessageCount;

2) Total of messages in the Subscription of Type A: ????

3) Total of messages in the Subscription of Type B: ????

It's possible to do this without using the Receive and Abandon functions ? Maybe using filters ?

Thanks in advance Rui

4

4 Answers

0
votes

This is not straightforward as message including its properties sits in serialized mode in service bus. You can't view the property of message unless you dequeue it.

I can think of one method where you can use peeklock , check the property , do the count and abandon it. This will be good if there is only one client as other clients can't see the message during the time it's locked.

You can also create different subscriptions instead of putting the type in property.

0
votes

Why not use 2 Subscriptions putting the appropriate message type in the appropriate subscription?

0
votes

Try this

 var subscriptionDes = namespaceManager.GetSubscription("TestTopic", "SubscriptionName");
            long messageCount = subscriptionDesc.MessageCount;
0
votes

You could add a filter so that messages of type A ends up in subscriptionA and messages of type B end up in subscriptionB.

Something like:

myNamespaceManager.CreateSubscription(subDescriptionTypeB, new SqlFilter("Type = 'B'"));

Then you can could the messages of each queue individually.

Problem would be if you need to ensure processing order of the messages.

You could also use the peek method to get a message from subscription without locking it. But would not be very efficient since you then need to get all messages, so I would say that this is a bad idea if you have many messages on the queue.