msmq fundamentals and how to be able to track in and out times of a message

2
votes

I've been through many tutorials and msdn docs like the following, but none of them explains what happens when you read a message off the queue...

  1. http://msdn.microsoft.com/en-us/library/ms978425.aspx
  2. http://msdn.microsoft.com/en-us/library/ms978430.aspx

Need a fundamental understanding of msmq first as I haven't actually worked with it before. Hence I have some questions which are rather "novice":

  1. What happens to a message once it is received by a client listening to the queue? Will it get removed from the queue automatically?
  2. What if a queue is being listened to by many clients? Will msmq guarantee that a message will reach any (and only) "one" of the listening clients?
  3. What is the real difference between a public/private queue? When should I go for a public queue?

Also I need to know how to track when a message came into the queue, and when it got consumed?

1
.netmsmq

1 Answers

3
votes

  1. When a message is taken from the queue, it is considered received and removed from the queue. Msmq is strongly ordered - you won't be able to receive a message before its preceding message. You can use a transactional queue if you want control over the removal of messages from the queue based on what receipt of a message means for your application. Unless it gets removed, you will continue to receive the same message over and over again. This is referred to as queue poisoning, and is a topic worth discussion in itself.

  2. A message is removed when received, therefore only one client at a time may receive a single message. You can combine receive with Peek if you want other semantics.

  3. Private queues and public queues are not very different in terms of programmatic access. The main difference is in how it is exposed to directory services. Private queues can still be exposed with the queue path. There is a good explanation regarding the types of destination queues on MSDN.

WCF has an MSMQ binding which abstracts over queues, so that's an alternative if you're more inclined towards working with contracts (though I wouldn't personally recommend it).