Today at work the dreaded words were uttered: "Well if it's not working by the end of the day lets just go for the pull every 1 second solution."
After implementing all of the long running processes to a pub/sub model, it was not pleasant to hear that. I wasn't going to just give up on that much energy poured into the current (and best) approach.
After adding tons of logging and hammering the server to see where the leaks sprung up, I cornered the culprit. If you are pulling from MSMQ ad nauseum, and you are in a multithreaded environment, you need to protect yourself from the thread unsafe methods "Send" and "Receive" on your MSMQ object - usually done by creating the MSMQ object for just long enough to do 1 operation.
The place where this was being done was not a multithreaded scenario, so I got rid of the creation and disposal of the MSMQ object between receives.
That did it.
The other lesson here is to be careful when you do have a multithreaded app pulling from MSMQ. You may see same messages go missing. I know there are other MSMQ features that guarantee delivery, etc, but I expect this integrity out-of-the-box.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment