Welcome to Windows Communication Foundation (WCF)
Top Tasks :

WCF Team Bloggers

Browse by Tags

All Tags » Answers » Queues   (RSS)

  • Single Reader for MSMQ

    My application needs to process messages from a queue in-order but multiple messages are being read at once. How do I make the service only use a single reader? There are two modes that control how many requests a service can process at once. InstanceContextMode controls when a new instance of your service is created; ConcurrencyMode controls the threading model for the service. When the InstanceContextMode is PerCall (or PerSession- the two are the same if you don't actually have a session), multiple instances of your service will be created with their own reader thread, up to a limit on the number of simultaneous instances. When the ConcurrencyMode is Multiple, multiple reader threads will be passing messages to a service instance, up to a limit on the number of simultaneous calls. If you want your service to be sequentially invoked with each of the messages in the queue, then you need to set both InstanceContextMode and ConcurrencyMode to Single. Next time: Getting Caught by Loopback Read More...
  • Sending to MSMQ with Integrated Authentication

    What are the rules for when a client needs to support Active Directory integration for sending to an MSMQ queue? The circumstances may seen mysterious for when you need the client to be joined to a domain to take advantage of Active Directory integration, but the rules turn out to actually be pretty simple. This should help you avoid seeing errors like the following: Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled. The channel factory or service host cannot be opened. The authentication mode of the MSMQ transport and the protection level of the message are interrelated, and these both are related to when you need to be using Active Directory. Rather than making you assemble the various combinations as a logic puzzle, I've digested the results into a table explaining when Active Directory is required to pass validation. Protection None Protection Sign Protection EncryptAndSign Authentication None Not required Not supported Not supported Authentication Certificate Not supported Not required Required Authentication WindowsDomain Not supported Required Required The same rules apply to both sides so you're covered for the explanation of the service as well. Next time: Customizing Exceptions for Validation Read More...
  • Subqueues

    How do I create a subqueue for dead lettering messages with MSMQ? Subqueues are a relatively new feature of MSMQ that do not actually involve creating a new physical queue. Instead, the subqueue represents a logical group of messages that are stored inside the parent physical queue. Messages can cheaply move between the parent queue and the subqueue. Since there is no physical queue being created, the distinguishing feature of subqueues must therefore be the address used to put messages into the queue. The subqueue syntax adds to the URI scheme for referring to a queue. Here is the URI scheme for net.msmq. net.msmq://hostname/[private/]queuename[;subqueuename] The bracketed sections in the above scheme represent the optional parts. Next time: Abort Instances on Errors Read More...
  • Optimizing MSMQ

    How can I speed up message processing when using MSMQ with WCF? For small gains, it is generally possible to eke out a few percentage points of performance by tuning parameters and settings according to the application domain knowledge you have. For large gains, you are likely going to have to think about larger design issues. In particular, a type of design issue that you should consider in your quest for large gains is to question what features are truly needed to build your application. This article is about a few of those feature decisions that you can make when using MSMQ together with WCF. Since these design decisions require building your application with a restricted set of features, there's no guarantee that these techniques are going to be applicable for you. It really just depends on the queue features you need versus the features you don't. I'm not going to mention features not primarily related to the queue, such as whether to use message security, although obviously the same type of analysis can be applied. Use the NetMsmqBinding instead of the MsmqIntegrationBinding. Of the two bindings, NetMsmq is faster than MsmqIntegration in most cases when similar conditions are applied (for example, both running without security). I have an earlier article describing the differences between the two MSMQ bindings . Disable transactional delivery of messages. The ExactlyOnce option controls whether messages are delivered without being lost or duplicated. Making a delivery guarantee requires that the queue be transactional and issue transactions for transfers. If you need best effort rather than exactly once, turning off transactions noticeably improves performance. Disable durable message storage. If you've already turned off transactions, then you can go significantly farther as well. The Durable option controls whether the queue survives restarting the MSMQ service. If you are using the queue to get asynchronous communication rather than reliable delivery, then leaving messages in a volatile store is another noticeable performance improvement. Pack more messages into the same transaction. Often you can't go as far as turning transactions completely off. A less dramatic step is to use the same transaction for multiple receive operations. The TransactedBatchingBehavior allows you to group messages up to a maximum batch size in a single transaction to amortize creating a transaction across multiple receive calls. Next time: Streaming and ToString Read More...
  • The Pool is Full

    What does the trace message "The pool of the native MSMQ messages is full. This may affect performance." mean? Is this a problem? I've seen some people on the WCF forums ask if this message is related to their MSMQ problems. It almost certainly is something that you can ignore. Let me explain what is happening here. MSMQ messages are heavyweight objects compared to normal XML messages. The MSMQ transports maintain pools of these native MSMQ messages as an optimization. There are separate pools for input and output messages and one pool per sender or receiver. Each pool has a maximum size to control the amount of memory used for pooling messages. There is no functional problem when the pool is either empty or full. The message pools are just a cache. When you try to get a message from an empty pool, a new message is allocated on the spot. When you try to return a message to a full pool, the message is disposed rather than being put into the cache. You should be able to tell what the trace message means now based on this description. However, there are some problems. Pooling looks like it will work fine when receiving on a NetMsmq channel. Pooling also looks like it will work fine when receiving on an MsmqIntegration channel. There's no setting for the pool size on an MsmqIntegrationBindingElement, but there is a hard-coded value of 8 in the code. This is the same as the default size for the NetMsmq message pools. When sending on a NetMsmq channel, the pool full message is actually traced when the pool is empty rather than when the pool is full. As far as I can tell, sending on an MsmqIntegration channel doesn't bother with pooling at all and simply creates a message every time through. Next time: Message Flow Interception Points Read More...

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us