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 application

So 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 successfully
What 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!

comments powered by Disqus