Wednesday, January 26, 2011
MSMQ PowerShell Scripts
I thought I'd hand out a couple of PowerShell scripts that I whipped up for our Server Admin friends. You can use these to do some basic things with MSMQ such as send a message, browse messages in a queue, and return messages to a source queue. Check them out: https://github.com/afyles/Blog/tree/master/PowerShell
Monday, January 24, 2011
Clustered MSDTC Mutual Authentication Gotcha Between 2003/2008 Servers
This is more of a mental note that anything else, but we ran across an issue with configuring our subscriptions database on a cluster. What we had set up was a 2008 cluster with our Publisher on it and a 2003 cluster with our subscriptions DB on it. MSTC was giving us a very distinct error:
[SQL: SELECT this_.SubscriberEndpoint as y0_ FROM [Subscription] this_ WHERE this_.MessageType in (?, ?, ?)]; Communication with the underlying transaction manager has failed.; The MSDTC transaction manager was unable to push the transaction to the destination transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02A)
The solution for this was that 2003 servers in cluster doesn't support Mutual Authentication. We ended up just using the Incoming Caller authentication between the clusters and everything started working again. Hope this helps someone else with the same problem.
[SQL: SELECT this_.SubscriberEndpoint as y0_ FROM [Subscription] this_ WHERE this_.MessageType in (?, ?, ?)]; Communication with the underlying transaction manager has failed.; The MSDTC transaction manager was unable to push the transaction to the destination transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02A)
The solution for this was that 2003 servers in cluster doesn't support Mutual Authentication. We ended up just using the Incoming Caller authentication between the clusters and everything started working again. Hope this helps someone else with the same problem.
Sunday, January 16, 2011
NServiceBus 3.0: Alternative Transports
Back in NSB 2.0 you could create your own transport but it took a bit of work. In 3.0 the concept has been better abstracted to allow us to write custom transports more easily. What was introduced was a new set of interfaces for us to implement:
Each is a file with the serialized data. Its as simple as that! It will be interesting to see what kind of other transports people plug in. I'm hoping that there will be some other queue based transports like MQ Series.
These simple interfaces have been plugged into the transport layer and makes it pretty painless to derive a new transport. In NSB 3.0, we already have an FTP transport and an Azure transport. I'm going to run through the FTP sample. First things first, you have to setup a couple of FTP sites on your machine. I followed the directions here. To get the sample to work you have to set up one on port 1090 and one on port 1091.
Next we need to mod the config to match our local one, here is how my config looked for the Client:
Here is the config for the Server:
Now we can fire the whole thing up and start sending messages. Once a message is sent you can see it in your FTP directory.
Each is a file with the serialized data. Its as simple as that! It will be interesting to see what kind of other transports people plug in. I'm hoping that there will be some other queue based transports like MQ Series.
Tuesday, January 4, 2011
NServiceBus 3.0: Fault Management
In NSB 3.0 we get some better support for message faults. Prior to 3.0 we were able to capture messages that faulted after a configurable number of retries. The difficulty with this is that since the actual exception was not captured with the fault, we as developers weren't able to do to much with that message besides blindly replay the message. In 3.0 this all changes in that there is a dedicated set of classes for fault management. Below is a class diagram of the hierarchy.
Out of the box we get 3 ways to manage faults. The Forwarder simply does what NSB has done in the past, which is move the message to a designated queue. The InMemory manager simply holds the message in memory for the lifetime of the host process. Lastly, the NHibernate Fault Manager allows us to store the message along with the exception that caused it to be faulted. This allows us to be smarter about how we handle faults.
To follow along you will need to download the 3.0 branch from GitHub and build it. From there open up the "FaultHandling" sample. When I downloaded this sample, it did not work right away. If you fire up the solution, nothing really happens. First and foremost you have to change the MyClient project endpoint to be transactional. If it is not, the fault management gets skipped right over in code. Simply edit the EndpointConfig.cs file to configure it AsA_Server.
Next we can dive to SQLLite to see what the output looks like. Note that the Message column hasn't been populated, but I'm hoping this simply a SQLLite issue.
From here we can now make better decisions on what to do with these faulted messages. I'm going to try using a full fledged SQL Server instance to see if the "Message" column gets populated. If not, looks like I'll be reporting a bug.
Out of the box we get 3 ways to manage faults. The Forwarder simply does what NSB has done in the past, which is move the message to a designated queue. The InMemory manager simply holds the message in memory for the lifetime of the host process. Lastly, the NHibernate Fault Manager allows us to store the message along with the exception that caused it to be faulted. This allows us to be smarter about how we handle faults.
To follow along you will need to download the 3.0 branch from GitHub and build it. From there open up the "FaultHandling" sample. When I downloaded this sample, it did not work right away. If you fire up the solution, nothing really happens. First and foremost you have to change the MyClient project endpoint to be transactional. If it is not, the fault management gets skipped right over in code. Simply edit the EndpointConfig.cs file to configure it AsA_Server.
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server {}The next issue I ran into is that the default profile(Lite) gives us the InMemory Fault Manager. The sample configured this via the IWantCustomInitialization insertion point. The only way I managed to get this to work was to move it to a custom profile, aptly named "Custom"
class Custom : IProfile{} class CustomProfile : IHandleProfile<Custom> { #region IHandleProfile Members public void ProfileActivated() { Configure.Instance.InMemorySagaPersister(); Configure.Instance.NHibernateFaultManagerWithSQLiteAndAutomaticSchemaGeneration(); } #endregion }Now that we have everything configured appropriately we can run MyClient. After launching the solution, simply enter an "s" to send a few messages. Sooner or later one of them will fail and start the retry cycle. Once that is complete, the NH Fault Manager kicks in and pushes the messages to SQLLite in my case. Here is what the output looks like:
Next we can dive to SQLLite to see what the output looks like. Note that the Message column hasn't been populated, but I'm hoping this simply a SQLLite issue.
From here we can now make better decisions on what to do with these faulted messages. I'm going to try using a full fledged SQL Server instance to see if the "Message" column gets populated. If not, looks like I'll be reporting a bug.
Monday, January 3, 2011
NServiceBus 2.5 Gets Official
NSB 2.5 is here!! It's mainly a lot of bug fixes. The most important one for us will be the bug fix for a Worker node to continue processing after a message failure. In 2.0, the Worker would take itself out of the loop after the failure and you'd have to restart it. Now in 2.5 it will continue processing.
I know I still owe the community some articles on 3.0. I've been busy upgrading to TFS 2010 here at work. The other thing is that I've been unable to get a full sample going for the Fault Management feature. I'm stuck on one final piece, which is getting SQLLite/NHibernate to work. Oddly, the transactions are committed and I can see data in SQLLite(the file), but I can't get anything when I query it. I'm hoping to solve that soon. If anyone has any ideas, let me know.
I know I still owe the community some articles on 3.0. I've been busy upgrading to TFS 2010 here at work. The other thing is that I've been unable to get a full sample going for the Fault Management feature. I'm stuck on one final piece, which is getting SQLLite/NHibernate to work. Oddly, the transactions are committed and I can see data in SQLLite(the file), but I can't get anything when I query it. I'm hoping to solve that soon. If anyone has any ideas, let me know.
Subscribe to:
Posts (Atom)