6
votes

I want to create a priority queue that has internal prioritization so that higher prioritized messags get popped first using ServiceStack. The ServiceStack RedisMQ implementation provides a Priority setter of type long on its IMessage interface. I would expect that message sent with a higher value on the Priority property would get popped first from the queue. My tests show that a message with Priority > 0 gets put on Redis "Mq:MyDto.priorityq" while any other value put the message on the normal in queue "Mq:MyDto.inq".

This is some sample code illustrating what I'm trying to accomplish:

         using (var producer = MsgFactory.CreateMessageProducer())
         {
            var lowPrioMsg = new Message<MyDto>(lowPrioDto);
            lowPrioMsg = (long)1;
            producer.Publish<MyDto>(lowPrioMsg);

            var highPrioMsg = new Message<MyDto>(highPrioDto);
            highPrioMsg.Priority = (long)100;
            producer.Publish<MyDto>(highPrioMsg);
         }

In other words, I want the highPrioMsg with Priority=100 to be popped before the lowPrioMsg with Priority=1. In practice, however, these message seem to follow a sequential FIFO principle.

Is there a way I can configure ServiceStack RedisMQ to work as I expect with internal Prioritization in the PriorityQueue?

Or is my only choice to either use the normal queue or the priority queue? In that case, why is a long used for the Priority setter instead of a boolean?

1

1 Answers

3
votes

In the ServiceStack Redis MQ IMessageService implementation your right in that the PriorityQ is just another FIFO Queue and all that happens when you send a Message with a Priority > 0 is that it gets published to PriorityQ instead of the standard InQ messages are normally published to.

Priority is a number so other ServiceStack MQ Providers have the ability to provide a different implementation, i.e. one which makes use of the Priority score. Currently PriorityQ in Redis is backed by a standard redis-server list which doesn't support prioritization of elements, eventually we may consider to change the implementation to use a sorted set which does allow sorting.

We also intend to ship different MQ Host providers for ServiceStack (e.g. RabbitMQ, ZeroMQ, ServiceBus, etc) where we'll make use of the Priority score where the underlying MQ broker supports it.