Daniel Halan has developed an MSMQ Viewer for NServiceBus:
I've lately been working with a scalable cloud solution, and then it's good to use a Service Bus for sending commands, events and messages around the network. Now I tried few MSMQ message viewers that are available, but they all lacked the real-time feedback that would be nice when debugging or just want to know what is happening behind the scenes. So from that a new small application grew, called "ServiceBus MQ Manager". It's a small application that will monitor queues with a set interval, and present the Events, Commands and Messages that are there, but also keeping messages that has been retrieved (deleted) from the Queue.
which you can download through a link on his blog.
I’m frequently impressed by the additions and changes to Windows as I spend more time on the Windows 8 Consumer Preview.
Here, for example, is how a the progress is now shown for a copy across my home network.
I think this is demonstrating to me how the destination is not able to keep up with the flow. I’m now intrigued to see if there is anything I need to do to improve performance.
And third for the day from Guatam is a problem managing MSMQ on a cluster.
MSMQ Management console on Win2k8 & WIn2k8 R2 Cluster not Visible
Seems that the MSMQ service on the physical node needs to run under Network Service.
Must set up a virtual cluster to test that out…
Another blog post from Guatam highlights the need to scale up some MSMQ parameters when there are many clients.
MSMQ 4 & 5 not receiving messages from Large Number of Clients
To improve performance, MSMQ caches user account information to reduce the overhead from checking if the sender of a message has adequate permissions to access a queue.
As with most caches, the size is fixed and old data is purged when there is no room left. Unfortunately, there is a potential situation where the clean-up process fails which prevents new clients from delivering messages.
To get round this blocker, make sure the cache is large enough to accommodate all possible users of the MSMQ system without needed to clean up.
This is done through the HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\UserCacheSize registry value (default is 253; maximum is 4 billion).
It’s good to see my ex-colleague Guatam putting out some MSMQ content after a 10 month hiatus.
MSMQ Performance degrades over time & MSMQ LQS folder is 100s of MB.
The files in the %windir%\system32\msmq\storage\lqs folder are configuration files for the machine’s queues, or cached configuration information in the case of public queues.
Inside these text files is a collection of parameters, such as “Label”, “QueueName” and “PrivLevel”. The largest value is the “Security” parameter which contains the access permissions on the queue.
Guatam reports that sometimes this value can get out of hand, leading to larger and larger configuration files that are too big to be easily read.
One workaround is to delete and recreate the affected queues. Also disable inheritance and apply security permissions directly.
Thanks to Seif Attar for highlighting this problem.
It seems MSMQ doesn’t like sending to computers with names longer than 15 characters (which some may remember is the NetBIOS limitation).
To try it out, I created a queue on a Windows XP machine with a computer name of VeryLongMSMQServer and sent off some test messages to
I requested acknowledgements so I could see any errors and wasn’t disappointed:
As soon as I renamed the machine to ShortMSMQServer, restarted and sent new messages to
the problem disappeared:
The messages are delivered to the destination’s queue manager in both cases but are rejected when the machine name is too long.
My suspicion is that this is a NetBIOS limitation. When I initially changed the machines computer name to one that was too long, Windows XP complained “The NetBIOS name of the computer is limited to 15 bytes. The NetBIOS name will be shortened to “VERYLONGMSMQSER”.:
I did try enabling the IgnoreOSNameValidation registry value in case that would help but no luck.
Udi Dahan briefly chats about MSMQ on his blog and provides a useful link:
Microsoft has put MSMQ in the Developer Preview of Server 8 (as Brian Buvinghausen has written here).
There’s good news on Brian’s blog:
“Finally! Microsoft added MSMQ to Server Core in Windows Server 8”
So it will be interesting to see how they got round the limitations of previous versions of Windows Server Core.
John Talarico shares a few lines of code to explain how he used TransactionScopeOption.Suppress to allow transaction messages to be sent within, but independent of, an ambient transaction.
Transactional logging outside of transactions
I’ve constructed a central logging system for a solution that involves routing and processing messages on multiple private queues (MSMQ) using WCF. Within a contract method of a WCF service, I do some logging.