--- title: "Tips for a successful MSMQ-enabled application" url: "https://osherove.com/blog/2005/8/22/tips-for-a-successful-msmq-enabled-application.md" canonical: "https://osherove.com/blog/2005/8/22/tips-for-a-successful-msmq-enabled-application.html" published: "2005-08-22T01:02:00" updated: "2005-08-22T01:02:00" tags: [".Net Original"] author: "Roy Osherove" description: "For the past few weeks I've been deep down inside a client's project. It's a large distributed application and one of the features I was working on made me realize just how little I've gotten the chance to use MSMQ in…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Tips for a successful MSMQ-enabled application By Roy Osherove August 22, 2005 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published August 22, 2005; technical details may be outdated. For the past few weeks I've been deep down inside a client's project. It's a large distributed application and one of the features I was working on made me realize just how little I've gotten the chance to use MSMQ in my projects, which is a total shame, really. MSMQ (Microsoft Message Queue) is a great bridge for helping you distribute messages between applications in an asynchronous manner (kinda like email). The syntax for using MSMQ is pretty easy (a couple of lines to send a message to a queue in the simplest form) and the benefits are huge if you need asynchronous conversations between your disconnected application components. However. MSMQ, like many other products and components, has its dark corners, as I've found during the past couple of weeks. I'll list them here so that I (and you) don't lose track of them. Some of them I've gotten straight off [Yoel Arnon](http://msmq.biz/) - MSMQ Guru and once part of the original MSMQ Team at Microsoft. [You can read his blog over here](http://spaces.msn.com/members/msmq/)(guess what its about..). 1. The problems with remote queues and COM+ transactions I had quite a simple scenario laid out for me. Get some info from a remote queue and try to insert it into a database. If the database insert fails, rollback the "get" from the queue as well so that the info stays queued for the next time around to be inserted into the DB again. Easy enough I tried to open a new transaction context using COM+ before calling "receive" from the queue and abort it if the DB failed. My integration tests (driven by NUnit) showed that even though Rollback was called, the message did not return into the queue. Weird because this was a transactional Queue and that should have worked. After asking Yoel it turns out that the fact that this queue was **remote**(residing on a different computer) meant that you couldn't actually do that. Remote queues do not support a transactional receive inside a transaction. If the queue had been local (on the local machine) this would have worked. "Send" does work in both ways, but receive is somehow special. There are ways around it, [detailed here](http://spaces.msn.com/members/msmq/Blog/cns!1pGjsZEQBluYM9y4YjJoNkTg!129.entry), but I've managed to get around it by doing the following: Create a local, private queue(cannot be used from remote machines) which acts as a transactional queue cache. The receive from the remote queue is actually a two-phase receive: get the info from the remote queue and put it into the local cache queue. Then do all your transactional work using the local queue. That guarantees that you never lose a message if you need to rollback on multiple actions. 2\. CanSend and CanRecieve = damn lies If your remote queue tells you that you can't sent or can't receive using its public boolean properties- don't trust it. It might be wrong. That's just how it is. 3\. Make sure you have the right permissions On windows Server 2003 in order to receive from a remote queue you need to explicitly go to the queue permissions page, click on the "Anonymous Logon" role and add the "Receive" ability to it, or you won't be able to receive from the remote queue It took me several hours to capture these important insights - so now you don't have to. If you have any more "Watch out for" tips on MSMQ - feel free to post a comment to this post. Good luck! ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Sep 9, 2006 ### [How to create your own Auto Login Remote Desktop Application](https://osherove.com/blog/2006/9/9/how-to-create-your-own-auto-login-remote-desktop-application.html) - Oct 16, 2005 ### [A better command line parsing class](https://osherove.com/blog/2005/10/16/a-better-command-line-parsing-class.html) - Aug 17, 2005 ### [\[Audio Interview\] Ingo Rammer and Christian Weyer On Distributed Applications Architecture And Practices](https://osherove.com/blog/2005/8/17/audio-interview-ingo-rammer-and-christian-weyer-on-distribut.html) - Aug 17, 2005 ### [Sherpa: Another Code/Layer/Application Generator](https://osherove.com/blog/2005/8/17/sherpa-another-codelayerapplication-generator.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/