2

I have been testing the NetMsmqBinding of WCF with a non-transactional queue. I have found that the service, the part that reads from the queue, will occasionally lose a message when it is closed.

For example, if I have a queue with messages of the numbers 1 - 10, and allow it to read the first five messages (1, 2, 3, 4, 5) before restarting, then the rest of the messages I might get are (7, 8, 9, 10). '6', the message it was going to receive before the service has closed is lost.

Is this because I'm using a non-transactional queue? Is there any way to prevent these messages getting lost without going transactional?

Thanks

Barguast
  • 5,926
  • 9
  • 43
  • 73
  • Do you see the missing message in your Dead-Letter queue? – Chris Jul 18 '12 at 15:20
  • Why do you not want to use transactional queues? – tom redfern Jul 18 '12 at 15:37
  • I don't want to use transactional queues because of the performance penalty. I need to allow for hundreds of messages a second at peak, so in this instance, it matters. Apart from solving the scenario above, there is no compelling reason why I'd need a transactional queue as the message processing is quite straightforward and won't be prone messages get lost through other means. – Barguast Jul 18 '12 at 15:59
  • You certainly are correct. This is one of the only valid scenarios to use non-transactional queues. – tom redfern Jul 19 '12 at 06:37
  • 1
    So you want guaranteed transactional processing, without using the built-in transactional nature of MSMQ? Have you performance tested it to see its affect. Writing 10 messages won't be an overhead. Writing thousands together will. – Dominic Zukiewicz Aug 27 '12 at 20:14

1 Answers1

0

If you are unable to use transactional queues then another solution to prevent loss of messages is to run one or more redundant queuing channels in unison.

What this means is that you send the message not once, but N times. Each message is then processed N times concurrently, and the net result should be that no messages are dropped.

The reason this works is that even though each processing channel could drop the occasional message, it's unlikely that all N processing channels would drop the same message.

The only thing you have to make sure is that your system can handle the added volume and can handle the messages idempotently.

tom redfern
  • 30,562
  • 14
  • 91
  • 126