MSMQ querying for a specific message

Question

I have a questing regarding MSMQ... I designed an async arhitecture like this:

CLient - > WCF Service (hosted in WinService) -> MSMQ

so basically the WCF service takes the requests, processes them, adds them to an INPUT queue and returns a GUID. The same WCF service (through a listener) takes first message from queue (does some stuff...) and then it puts it back into another queue (OUTPUT).

The problem is how can I retrieve the result from the OUTPUT queue when a client requests it... because MSMQ does not allow random access to it's messages and the only solution would be to iterate through all messages and push them back in until I find the exact one I need. I do not want to use DB for this OUTPUT queue, because of some limitations imposed by the client...

Shoring

Answer 1

You can look in your Output-Queue for your message by using

var mq = new MessageQueue(outputQueueName);
mq.PeekById(yourId);

Receiving by Id:

mq.ReceiveById(yourId);

Sachasachem

Answer 2

A queue is inherently a "first-in-first-out" kind of data structure, while what you want is a "random access" data structure. It's just not designed for what you're trying to achieve here, so there isn't any "clean" way of doing this. Even if there was a way, it would be a hack.

If you elaborate on the limitations imposed by the client perhaps there might be other alternatives. Why don't you want to use a DB? Can you use a local SQLite DB, perhaps, or even an in-memory one?

Edit: If you have a client dictating implementation details to their own detriment then there are really only three ways you can go:

1. Work around them. In this case, that could involve using a SQLite DB - it's just a file and the client probably wouldn't even think of it as a "database".
2. Probe deeper and find out just what the underlying issue is, ie. why don't they want to use a DB? What are their real concerns and underlying assumptions?
3. Accept a poor solution and explain to the client that this is due to their own restriction. This is never nice and never easy, so it's really a last resort.

January

because the client does not want us to use any DB (even though i tried to explain the reason...)... the results list MUST be persistent through system failures, and MSMQ message can be set as recoverable... – Shoring

i thought of storing a custom object inside the MSMQ (for persistence only), but this raises the problem of concurrent accesses, because i have multiple threads running at the same time that can access this object... adding a writerLock on it would affect the performance of the entire system... – Shoring

Answer 3

You may could use CorrelationId and set it when you send the message. Then, to receive the same message you can pick the specific message with ReceiveByCorrelationId as follow:

message = queue.ReceiveByCorrelationId(correlationId);

Moreover, CorrelationId is a string with the following format:

Guid()\\Number

Riding