Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Nine Tips to Enterprise-proof MSMQ : Page 2

MSMQ is a transformational development tool, but it's not without reliability and performance problems. Help enterprise-proof your MSMQ installations with these nine tips.

Tip 3: Avoid Transactions If Possible
MSMQ supports transactions for environments sensitive to ATOMIC operations. To improve performance when using transactions, MSMQ supports internal transactions—either all messages are sent or none are sent; however, to make the product more extensible, MSMQ also supports COM+-style DTC transactions, known as extexternalernal transactions. This feature allows developers to enlist the sending or receiving of a message in a transaction that involves committing other transactions such as database updates. Unless this is a feature that is absolutely required by your application, steer clear of transactions involving MSMQ. The overhead involved in transaction support for internal transactions is close to 100%. Using DTC-style transactions incur an even higher overhead typical of two-phase commit operations.

MSMQ supports internal transactions using the MessageQueueTransaction object. This object coordinates of message sends and receives inside a transaction boundary. It also exposes methods used for both controlling the outcome of a transaction and monitoring the state of existing transactions. The following code shows an example of sending two messages in the context of an internal MSMQ transaction.

Imports System.Messaging Dim msmqTransaction As New MessageQueueTransaction() Dim msmqQueue As New MessageQueue( _ "FormatName=OS:testbox\TestQueue") Dim msmqMessage1 as New Message Dim msmqMessage2 as New Message msmqTransaction.Begin() Try msmqQueue.Send(msmqMessage1, msmqTransaction) msmqQueue.Send(msmqMessage2, msmqTransaction) msmqTransaction.Commit() Catch msmqTransaction.Abort() Finally msmqQueue.Close() End Try

As you can see in the previous code example, MSMQ uses imperative support for internal transactions—that is, you explicitly request transaction services. To support external transactions, you implement a .NET serviced component by inheriting from the System.EnterpriseServices.ServicedComponent class and by setting several .NET Framework attributes that declare support for transactions. External transactions use a declarative model.

The following MSMQSampleApp class shows how to implement declarative external transactions

Imports System.EnterpriseServices <Assembly: ApplicationName("MSMQSampleApp")> <Assembly: ApplicationActivation(ActivationOption.Server)> <Transaction(TransactionOption.Required)> Public Class MSMQSampleApp Inherits ServicedComponent Public Function SendShipperNotification() as Boolean Try Me.SendMSMQNotification(strCompany, strMessage) Me.WriteSQLAuditEntry(strCompany, strMessage) ContextUtil.SetComplete() Return True; Catch e As Exception ContextUtil.SetAbort() Return False; End Try End Function End Class

This class first declares support for transactions using the appropriate .NET Framework attributes. It then defines a method that both sends an MSMQ message and writes an entry to a database inside the context of an external transaction. As you might expect, either both actions occur, or neither occurs. Unlike internal transactions, where MSMQ brokers the transaction, Microsoft's DTC acts as the transaction broker for external transactions. The example SendShipperNotification function sends a notification message to a shipping company using MSMQ. To maintain consistency the application also writes an audit log entry to a SQL database via the WriteSQLAuditEntry method.

Tip 4: Use Windows Security Sparingly
MSMQ uses the standard Windows security model. You can configure queues to permit only senders and receivers with appropriate security privileges. Security is an ever-increasing issue at most companies. I have found that the tradeoff for including Windows security in messaging is that it takes about 2.5 times as long to send the same messages. By configuring MSMQ not to send the security descriptors associated with the sending application, you can obtain significant performance gains. To configure MSMQ not to send a security descriptor with the message, set the message property AttachSenderID to False (the default is True), for example:

msmqMessage.AttachSenderId = False

Tip 5: Use Private Queues
MSMQ supports both public and private queues. The primary difference is that public queues, and their properties, are published in Active Directory. This makes it easier to find queues based on their name or properties anywhere in an enterprise. I have found this feature to be of little use, since I generally know which queue I am going to send a message to.

I encourage you to use private queues whenever possible. Not only are they slightly more efficient, but they are also less prone to problems with AD (no one has problems with AD do they?). When AD is misbehaving, or when the machine hosting your queues cannot reach the MSMQ service running on one of your AD servers, the public queues hosted on the machine cannot be configured and no queue properties can be obtained. You will be unable to create new queues, delete existing queues, or modify the queues until the issue is resolved.

Tip 6: Use Direct Format Names to Open Queues
When opening queues, MSMQ provides several options for specifying the queue you would like to open. The easiest way to specify a queue name is to use a simple pathname such as testmachine\testqueue. This naming convention specifies that you would like to open a queue named testqueue hosted on a machine named testmachine. When opening a queue in this manner, MSMQ consults the directory service to resolve the location and properties of the queue.

By using direct format names with private queues, you specify the exact queue location and name, circumventing the overhead involved in consulting the directory service. An example of a direct format name is TCP:\private$\TestQueue. There are other ways of specifying a direct format name, for example, you can specify a machine name as in OS:textbox\private$\TestQueue, rather than an IP address. Both direct format names are equivalent, except that the latter incurs the slight overhead of looking up the machine's IP address. To obtain the most reliable and highest performing message queuing environment, use direct format names and private queues whenever possible. This MSDN article provides other examples of format names.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date