|
|
Browse by Tags
All Tags » Indigo » Queues (RSS)
-
Over the past few days Tom Hollander has been posting his experiences hosting a queue-based WCF service in IIS. These posts go into a lot of detail about setting up the machines, configuring the service, and troubleshooting problems. If you're looking for a step-by-step guide, this is a great resource. MSMQ, WCF and IIS: Getting them to play nice (Part 1) MSMQ, WCF and IIS: Getting them to play nice (Part 2) MSMQ, WCF and IIS: Getting them to play nice (Part 3) Read More...
|
-
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...
|
-
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...
|
-
Here's a quick guide to how an address that uses the net.msmq scheme in WCF gets turned into an actual MSMQ address. There are three transfer protocols used with MSMQ: native, SRMP (SOAP Reliable Messaging Protocol), and SRMPS (SOAP Reliable Messaging Protocol Secure). Each of the transfer protocols translates addresses slightly differently. For a given net.msmq address, we'll first check the transfer protocol. If the transfer protocol is SRMP or SRMPS, then the MSMQ address is going to be a direct address. The only difference between SRMP and SRMPS is that SRMP uses the http scheme while SRMPS uses the https scheme. The MSMQ address produced from net.msmq://hostname:port/queuename is DIRECT=http://hostname:port/msmq/queuename. Having a port is optional, and this part of the address is omitted if no port is specified. A private queue name is written as private/queuename in net.msmq but translates to private$/queuename in the MSMQ address. It's illegal to include the dollar sign in a net.msmq address. If the transfer protocol is native, then the MSMQ address is either going to be a GUID address or a direct address. A GUID address is created if the binding has been configured with UseActiveDirectory set to true. The GUID uniquely identifies the queue. Otherwise, the MSMQ address produced from net.msmq://hostname/queuename is DIRECT=OS:hostname\queuename. Unlike SRMP, a port is never specified with the native transfer protocol. Again, a private queue name is written as private/queuename in net.msmq but translates to private$\queuename in the MSMQ address. Finally, if the hostname is an IP address, then the resulting MSMQ address instead is DIRECT=TCP:hostname\queuename. Next time: Attribute Driven Transactions Read More...
|
-
MSMQ has gotten a bit of an upgrade in the latest releases, particular in the area of poison message handling. Let's look a bit though at what users of Windows Server 2003 can do in the meantime before the next version of Windows Server is officially available. The interesting control to look at for poison message handling is the set of actions that are available when a message is discovered to be poisonous. MSMQ 4 has four options for handling these messages: The Fault option causes an MsmqPosionMessageException to be thrown and the listening service stops processing messages. The offending message is left in the original queue. The Drop option causes the offending message to be discarded. The Reject option causes a rejection notice to be sent back to the submitter. The offending message is removed from the queue. The Move option causes the offending message to be moved from the original queue to a separate poison queue. If you don't want to lose messages and you don't want your service to shut down, then the most desirable option is to move the offending message to some other queue. Unfortunately, the Reject and Move options are not available for MSMQ 3. Your only choices are to fault the listening service or drop the message. However, you can use the Fault option with WCF extensibility to fake more sophisticated poison message handling strategies at some cost to speed. The essence of the trick is to use the fault notification of the listening service to perform some corrective action. For example, here's the strategy that you would use to replicate the move option. Register an IErrorHandler to catch instances of MsmqPoisonMessageException as they occur. When a poison message is encountered, the service is shut down and your error handler is called. Use the message identifier in the exception to find the offending message in the original queue and move it to a separate queue that you've previously created. At the end of your error handler, restart the service if you were able to move the message. The third step can be replaced with whatever action you'd like to customize your poison message handling behavior. Next time: Measuring Reliable Session Speed Read More...
|
-
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...
|
-
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...
|
-
Are you someone that's interested in using Service Broker together with WCF? If so, would you like to answer a few questions? I went surveying for SSB users at a Microsoft MVP event last night, but now is your chance to participate as well. I got to talk to five or six casual and not-so-casual SSB users, including SSB champion enthusiast Harry Pierson (second place: Jesus Rodriguez ). Here are some points that I picked out where I'd like some more data. Are you interested in SSB because you'd like to have your service closer to the database? How close is close enough to the database? Are you interested in SSB because you need durable, duplex messaging between two services? Do you need exactly-once-in-order message delivery? Are you interested in using SSB from WCF because you want a better asynchronous messaging experience than MSMQ? What makes you prefer SSB to other queuing products? Are you interested in having your data contracts defined in WCF, SQL, or both? Read More...
|
-
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...
|
-
Last time we looked at the idea of poison messages in queues - messages that are permanently unprocessable. If we don't handle a poison message carefully, then we will be locked into a permanent cycle of requesting the message from the queue, failing to process the message, and returning the message to the queue. There are many different strategies that can be applied to reduce or eliminate the resource waste of these futile cycles. I'll first look at the primary strategy that MSMQ uses for poison messages. Tomorrow, we'll finish off the series by looking at a comparison of this approach with various other strategies. First, how do we detect that a message is permanently unprocessable? The application may be able to tell the queue this, but we can't guarantee that the application will recognize every potential poison message. We can approximate the idea of being permanently unprocessable by saying that there is a threshold for number of failures beyond which we expect this failure pattern to continue indefinitely. On the MSMQ binding, that threshold is controlled by the ReceiveRetryCount. Now, assume we've got a poison message. The most common way of dealing with a poison message is to move it out of the main queue and into some other queue where no processing will take place. That other queue is commonly called a dead-letter queue. Up to version 3 of MSMQ, the dead-letter queue is the end of the line. A downside of the dead-letter queue is that some administrator has to flush the messages out in case they can be corrected or in case we have accidently classified a temporary processing failure as a permanent processing failure. Version 4 of MSMQ introduces an optional intermediary step between the main queue and the dead-letter queue. Remember that while we were spinning doing retries on the poison message, other messages were not getting processed. The addition to the strategy is to have a retry queue. Like the dead-letter queue, the retry queue does not process messages. However, after a period of time, set by the RetryCycleDelay, the message gets moved from the retry queue back into the main queue. This process can repeat a number of times, up to the MaxRetryCycles. The retry queue allows us to attempt processing many more times without impeding the progress of the service as much. Next time: More Poison Message Handling Read More...
|
|
|
|