MSMQ via C# - ACK that message received?

Question

I'm sending a message to a private queue via c# :

MessageQueue msgQ = new MessageQueue(@".\private$\aaa");
msgQ.Formatter = new XmlMessageFormatter(new[] { typeof (String) });
msgQ.Send(msg);

It does work and I do see the message in the queue.

However, is there any way to get an ACK whether the message got to the queue with success ?

ps

BeginPeek and PeekCompleted is an event which is raised when a message becomes available in the queue or when the specified interval of time has expired. it is not helping me because I need to know if the message that I sent was received by msmq. BeginPeek will be raised also if someone else entered a message to the queue. and the last thing I want is to check via BeginPeek - from who this message comes from.

How can I do that?

ps2

Or maybe I don't have to worry since msgQ.Send(msg); will raise an exception if a message wasn't inserted....?

Shiekh

Answer 1

I think what you are trying to do should not be handled in code. When you send the message, it is placed in the outgoing queue. There are numerous reasons why it would not reach the destination, such as a network partition or the destination queue being full. But this should not matter to your application - as far as it is concerned, it sent the message, it committed transaction, it received no error. It is a responsibility of the underlying infrastructure to do the rest, and that infrastructure should be monitored to make sure there are no technical issues.

Now what should really be important to your application is the delivery guarantees. I assume from the scenario that you are describing that you need durable transactional queues to ensure that the message is not lost. More about the options available can be read here

Also, if you need some identifier to display to the user as a confirmation, a common practice is to generate it in the sending code and place it in the message itself. Then the handling code would use the id to do the required work.

Unfeeling

My iis and msmq computers are the same machine .if so , Does a message is stored in the outgoing queue before it goes into the incoming queue ? Also , there is no more than 1 operation to complete in the transaction ... So why dont you think transactional queue is not recommended ? – Shiekh

Well, as pointed in the link in my answer, if the queue processing service crashes while processing non-transactional queue, the current message is lost. Use non-transactional if this is OK. As for the other question, if all communication is local, the outgoing queue should not be used. – Unfeeling

Answer 2

Using transactional queues and having all your machines enroll in DTC transactions likely would provide what you're looking for. However, it's kinda a pain in the butt and DTC has side effects - like all transactions are enrolled together, including DB transactions.

Perhaps a better solution would to be use a framework like MassTransit or NServiceBus and do a request-response, allowing the reviecer to respond with actual confirmation message say not only "this has been delivered" but also "I acknowledge this" with timeout options.

Whorton

no , im not looking for this. im looking for a code to check that a message was inserted correctly to the queue. that's all. no DB . – Shiekh

Well, transactional queues confirm entry into the queue when the transaction is closed. But if the queue is transactional, when you read off it, that's also in a transaction scope. Which is where you get DTC involved. – Whorton

Answer 3

As Oleksii have explained about reliable delivery.

However this can effect on performance.

What I can suggest is:

Why not create a MSMQ server on the machine that is sending MSG to other system.

What I am thinking is

1. Server 1 sends MSMSQ to Server 2
2. Server 2 receives adds to queue
3. Server 2 process queue/fire your code here to send a MSMQ msg to Server 1
4. Server 1 receives MSG (any successful msg with MSGId)
5. Do your further task

This approach can be an extra mile, but will keep your servers out of performance Lag.

Jerk