MSMQ concurrent processing design issue

Question

I have a windows service written in C# that reads from MSMQ and based on the type of the message it assigns them to Agents that process that message in a worker thread. The application starts with no agents and are created dynamically at runtime as messages arrive in the MSMQ

Here is a basic figure of how it works:

If the agent worker thread is busy doing work the message is queued to its local queue. So far so good. But if for some reason if the service is stopped, the local queue content is lost.

I am trying to figure out what could be the best way to handle this scenario. Right now the local queues are a System.Concurrent.ConcurrentQueue. I could probably use a Sql Ce db or some other persistent storage, but i am worried about performance. The other thing in my mind is to read from MSMQ only when agents are ready to process message, but the problem is that I don't know what message the MSMQ will contain.

What possible approaches can I take on this issue?

Haletta

Answer 1

Your design is basically implements the following pattern: http://www.eaipatterns.com/MessageDispatcher.html

However, rather than using actual messaging you are choosing to implement the dispatcher in multithreaded code.

Rather, each processing agent should be an autonomous process with it's own physical message queue. This is what will provide message durability in case of failure. It also allows you to scale simply by hosting more instances of the processing agent.

Glyndaglynias

Not sure you need to have separate processes - handy from an isolation PoV but tricky to coordinate. Definitely agree with having separate message queues for each agent (created programmatically using some kind of convention that allows the queue name to include some kind of identifier that links it to the agent that is responsible for it's messages. Then during service startup you can recreate any agents that have queues already in existence. – Driskill

Answer 2

I have built a similar system dependent on Redis. The idea is that it provides memory - fast data access isolated from the rest of the application, and will not shut down when my service does. Furthermore, it will eventually persist my data to the disk, so I get a good compromise between reliability and speed.

If you designed it so that each client read from its own message queue that would be hosted in Redis, you could keep the queue independent from the service's downtime, and each worker's load apportioned when you next start the service.

Couldst

I'd love to use Redis here, but don't you think it would be a overkill? – Haletta

Not at all. It's extremely light, and it does what it was designed for well, so instead of brewing and debugging something new all by yourself, you can use something that can do the job for you. Alternatively, you could use memory mapped files to achieve quick access to some kind of permanent storage, but there are some complications, and I don't know about thread safety... – Couldst

Answer 3

Why don't you simply create two new msms queues to receive the messages for Agenta and agentb, and create a new agent that ( transactionally ) fetch the command from the main queue and dispatch the message to the proper agent queue ?

Glower

Actually the Agents are created dynamically based on the type of message that arrives in MSMQ. The type of message can vary from 1 to n. So I cannot create a separate queue for potentially unknown type of messages. – Haletta

ObaidR why not ? you can create a queue programmatically, is n potentially how big? – Glower

n will be around 15~20 maybe. But then I'll have to change the system at the other end where it will put the messages in separate queues based on the message type. I was wondering if I could handle this in my service somehow. – Haletta

@ObaidR you can by using some DB: SQlite for example, but I really suggest the multi queue architecture – Glower