debugging a windows service that couldnt connect to an activemq broker
Wed, Jul 4, 2012
This was a seriously obscure bug it turned out. It was so obscure I turned to stackoverflow to ask about it. I’ve written a C# assembly that wraps the Apache NMS library to provide applications with messaging functionality and the NUnit tests for the DLL run fine but when I tried using the DLL from the main Windows Service that I’m working on the connection to the broker always failed. And to boot, the exception info was not helpful:
Error in the applicationSo I hacked the service up a bit, copying the failing code into its own method so I could run it directly in Visual Studio:
mxConnection = mxClient.GetDurableTopicConsumer(brokerURL, clientID, topicName, null, messageHandler, errorHandler);This code worked fine in NUnit when testing the original DLL and it also worked when I copy/pasted it into a Console App. But whenever I ran it in Visual Studio the connection failed. Debugging further I got down to ApacheNMS:
Apache.NMS.NMSConnectionException was caught Message=Error connecting to URL:61616. Source=Apache.NMS.ActiveMQ InnerException: System.Net.Sockets.SocketException Message=The operation completed successfullyWhat on earth was all that about? A failed connection that completed successfully. It was beginning to stink. So, being a recent returner to Windows development after years of Java/Unix I turned to stackoverflow with a question. I already knew about the user permissions problems you can get with services but I’d tried them all, to no avail but the comment about WebClient was interesting. So I cobbled up a few lines of code to try and connect to a web site from the service and it failed too but it had the solution in its stack trace:
System.Net.WebException was unhandled Message=An exception occurred during a WebClient request. Source=System … Only one <configSections> element allowed per config file and if present must be the first child of the root element …I had a ‘startup’ element at the top of my App.config. Moving the ‘configSections’ element to the top solved the problem. So a very big thanks to stackoverflow and bryanmac in particular for offering a suggestion that led to what is most definitely the most obscure bug I have ever seen. Welcome back to Windows!