1

We've been using SSSB 2008 for the past year, and it's been wonderful. (Well, compared to MSMQ anyways.) However, we've only been using same-database queueing, not the routing features.

Some changes in our app now require that we route messages. Up until now, we've been doing "fire and forget" - SEND a message and end the conversation. I'm not worried about the receiving app failing as much as one of the databases getting misconfigured. If someone messes up the certificates, then we'll get an Error message back from SSSB.

When we get these errors, is there any way to get the original message object? For immediate errors when the message is still in the transmission queue, it's easy. But after going over the network, it appears that the message is "gone".

If this is the case, what's the common way to deal with it? I'm thinking of writing the message and ID to a "QueuedMessages" table, then having a procedure activated on the sending queue to either delete the message on receiving an EndDialog, or setting a flag/logging when an error is received. Alternatively, if I can loosen the business requirements, I might just be able to keep send items in the sending process's RAM, and have it check the queue for Error/EndDialog. (Motivation for in-RAM would be performance -- we plan on doing about 400 messages/sec outbound with very little resources, running SQL Express.)

Any comments in general?

MichaelGG
  • 1,739
  • 8
  • 25
  • 30

1 Answers1

2

If the message doesn't make it to its destination, then you should be able to get the message from the sys.transmission_queue.

mrdenny
  • 27,174
  • 4
  • 41
  • 69
  • Wow... I could have sworn I looked there - honest! Yea, you're absolutely right. So I just need to check the queue for such things and log them, as well as closing any dialogs I get an EndDialog for. Perfect. – MichaelGG Sep 15 '09 at 23:05
  • Oh, would this apply if more than one hop was involved, as if with a forwarding machine? – MichaelGG Sep 15 '09 at 23:08
  • 1
    Yes, the message would be sitting in the sys.transmission_queue on one of the servers, not necessarily the sending server. You might have to look in the forwarding machines sys.transmission_queue. – mrdenny Sep 16 '09 at 00:34