![]() ![]() So my IT Manager would create a bunch of monitors in Microsoft SCOM (may have been MOM at the time) based on queue sizes and performance counters and all that sort of stuff. I can think of one instance where in retrospect I’m sure my crappy code was to blame – a “command and control” sort of component implemented in an IWantToRunAtStartup that should have been a bunch of never-ending sagas instead. It wasn’t unheard of for an endpoint to appear to be healthy as far as the Process Manager was concerned, but for some reason to have stopped processing messages for whatever reason. Meanwhile it was never the tool I wanted or really needed it to be, and addressing its shortcomings was always my lowest priority.Īnd MsmqRemote even begin to cover everything we needed to effectively monitor a production system. I don’t have any idea how many hours I ended up pouring into that tool, but what I do know for sure is that I wasn’t solving any business problems during that time. And sometimes the daemon process would just completely crap out, because as you’re probably already aware WCF is such a joy to work with.(Sarcasm intentional.) ![]() It didn’t always work quite right either, especially when a queue would fill up with a significant amount of messages, everything would slow to a crawl. It was always the minimum necessary to get the job done which meant that it was always pretty shitty. ![]() It wasn’t refined or nice or even very usable. The tool suffered from the same problem that plagues many internal tools. ![]() After selecting a queue, it would ask for a list of messages, which would appear in the third pane, and finally, selecting a message would again go to the server to ask for message details and contents, and the XML representation of the message would appear in the fourth and final pane. Then it would ask the server for a list of queues, which would appear in the second pane. First you selected a server which was populated from a config file, that told the application which WCF service URL to try to connect to. The client application was a WinForms monstrosity with four panes. It contained a copy of the relevant ReturnToSourceQueue code so that it could do that operation as well. It could move and delete messages, all based on MSMQ code I had to write myself. It had the capability to list queues, and get details about the messages in each queue, and return all of this information to a client application via a WCF service hosted over TCP. It was responsible for interacting with MSMQ and NServiceBus on each server. So I built a tool called MsmqRemote that had a daemon process that I installed on every single server that hosted any NServiceBus queues. And I certainly didn’t want to remote desktop into the server to run ReturnToSourceQueue.exe, and have to potentially copy and paste a message id into a console window over remote desktop. Let’s face it, that tool is heinous enough when run locally. I didn’t want to remote desktop into a server and launch Computer Management to view the Message Queues. Don’t Build Your Own Monitoring Toolsįor the first system I ever built on NServiceBus 2.x, I built my own monitoring and management tools because I had no other choice. NServiceBus 4.x is a fantastic platform to build distributed systems, but as of the release of NServiceBus 4.0 in July 2013, the big thing still missing was the ability to effectively debug a messaging system (let’s face it, gargantuan log files don’t count) and monitor a distributed system in production to make sure everything isn’t running off the rails. And if you need some bit of config, you can run a helpful PowerShell cmdlet from the Package Manager Console to generate it for you along with XML comments describing what every knob and lever does. Now you just reference a the NServiceBus.Host NuGet package and it sets all that stuff up for you. NServiceBus 3.x and 4.x changed all that. Then you start debugging and hope you didn’t screw anything up. You never write this yourself you always copy it from somewhere else.” Not exactly a glowing recommendation right? As I was once quoted during a live coding demo, “Don’t worry I have been doing this for years. Enter a bunch of required XML configuration. Build so that the EXE is copied to the bin directory. The developers at Particular Software (a name change from NServiceBus Ltd – a lot of people seem to think they were bought and this is not the case) are really obsessive about making a powerful framework as easy to use as possible, and I salute them for that. What really struck me during the writing process was how much easier people learning NServiceBus 4.0 were going to have it than I did when I learned NServiceBus 2.0. Writing about something that’s still very much in flux is definitely a challenge, and to some extent I was definitely learning as I went. When I first started writing Learning NServiceBus, I was targeting Version 4.0 which, at that time, was still several months away from release. ![]()
0 Comments
Leave a Reply. |