tags:

views:

460

answers:

2

I'm doing testing against some software I've written. The test enqueues messages into MSMQ via WCF at a rate faster than than my software can dequeue and process them. This shouldn't be a problem, since that is MSMQ's intended purpose, but if I enqueue enough messages to where it's taking my software more than 24 hours to process, those messages will get moved to the "Transactional dead-letter messages" queue and have their Class set to "The time-to-be-received has elapsed".

The only configurable that I can find is on the binding itself:

<bindings>
  <netMsmqBinding>
    <binding timeToLive="7.00:00:00" /> <!-- 7 days -->
...

I use this binding both when enqueuing and dequeuing and it doesn't seem to do the trick. Setting the value 2 seconds does have an effect, but setting it longer than 1 day, including to its max value (24 days) does not.

Is there another way to lengthen this time-to-be-received window? I can't find anything else to configure (when sending the message or creating the queue).

A: 

I'm not 100% sure, but I believe that the TimeToLive property only sets the Time-To-Reach-Queue msmq property, but I don't know of a built-in way right now of setting the Time-To-Be-Received property...

tomasr
Thanks for the input. This is a bit of an annoying problem. I've seen some recommendations advising that I create a custom dead-letter queue, monitor it, and automatically retry messages that appear in it, but that seems like a huge to do over such a simple issue. My code is slow and just needs more time! :)
Langdon
Oh I agree, its annoying, no argument there :) Out of curiosity, is your server CPU-bound or IO-Bound?
tomasr
CPU bound at the moment (we're doing load testing and benchmarking to try and improve things). I'm able to send messages to an asynchronous endpoint hosted on IIS using wsHttp much more quickly than I'm able to forward them on to an MSMQ WCF endpoint, process, them there, and ship them back to to subscribers... it's an implementation of WS-Notification. I've got a few ideas going forward -- we're not doing any channel caching, and I think it costs 1/10th of a second every time we create a new channel.
Langdon
A: 

The timeToLive attribute on the binding itself is, in fact, the only configurable necessary. I went back through all my configurations and apparently missed a spot. From "Programming WCF Services":

The TimeToLive property is only relevant to the posting client, and has no affect on the service side, nor can the service change it. TimeToLive defaults to one day.

I've had the test running all weekend now, progressing 1,000,000 messages. Nothing has ended up in the dead-letter queue yet.

Langdon