I’ll start this with a little tale, a tale of mystery and confusion. So … it starts with the installation of StreamInsight 1.2. As my team moved to 1.2, we (I) also decided to change the name of the instance that we were using for development. Even though we’ve been working with 1.2 for a little while, this gave us a clean break from the 1.1 assemblies. We also uninstalled 1.1 completely and started fully using all of the new cool stuff with 1.2, including performance counters (which are configurable). Now, we primarily use the embedded hosting mode with StreamInsight because we are building a platform that accelerates StreamInsight applications and provides additional services around our framework. So, let’s say the new instance was called “MyStreamInsight” and the StreamInsight service host was installed as well – because we will be doing work to support that model as well. Naturally, we also expose the management service. And the URI that we were using was “http://localhost/StreamInsight/MyStreamInsight”.

After making all of these changes to the configuration, I set about to run and test. Everything looked cool. There were no exceptions in startup. Keep this in mind.

So … I went to take a look at the performance counters that had been turned on – just to make sure that it was all working. We were using the extension method for performance counters that I published previously. The StreamInsight server instance counters were in there; that was good (they are always enabled, btw). But … no counters for adapters and queries. WTF, mate? I go to fire up the Event Flow Debugger. “Maybe”, I was thinking, “the queries aren’t started.” I couldn’t imagine why that would be but I tend to be pretty methodical about debugging so I didn’t assume anything. “Ass” of “U” and “Me”, right? Though in this case, it’d just be Me. I try to connect and get the following exception: “It was not possible to establish a connection with the Microsoft StreamInsight server”. Clicking on the details, I got the following:

The HTTP service located at http://localhost/StreamInsight/MyStreamInsight is too busy.
-------------------
The remote server returned an error: (503) Server Unavailable.

Huh? Remember: There were no exceptions on startup. And it was all working before we fully removed 1.1 installed only the 1.2 RTM bits; we had been working with the 1.2 beta bits for a while (we’re on the StreamInsight Advisory Board and were on the Early Adopter program). WTF, mate? I restarted the process with a breakpoint at the code that initialized the management service. Nope … no exceptions.

I’ll skip over everything that I did. But … I can tell you that it reminded me why I shave my head; it makes it MUCH harder to pull your hair out. What finally worked was this: we changed the management service URI to http://localhost/Logica/MyStreamInsight - something different from the URI that the StreamInsight service used. And then … viola! Everything worked. Hmmm. So I looked in the MSDN documentation and didn’t see anything there about this but … well … that’s what it was. And no, the StreamInsight Service was not started.

The moral of this tale: Use a different URI from the StreamInsight service URI when publishing the management service using the embedded model.

I’ve just posted this to the SQL Saturday web site. All of the content that was presented is there, including the PowerPoint and the code. There’s quite a bit of stuff in the code that we simply didn’t have time to show. There are two text files in there with several different query patterns that you can copy and paste into place. This sample does require StreamInsight 1.2, so make sure that you have at least the evaluation version installed.

One of the new features in StreamInsight 1.2 is performance counters. These give you a very robust and easy way to test and monitor performance of your StreamInsight application and were much needed. The counters are enabled at the StreamInsight Server and Application level all the time but you need to specify and enable the individual queries that you want monitored as well. Enabling a query for performance counters will also hook up both the input and the output adapters, which help you understand if you have bottlenecks or poor performance in them as well – though there is a performance hit (though relatively minimal) for this. Very cool stuff. But … like the query state … it’s a bit warty (IMHO) in some of the details. Fortunately, it’s nothing that we can’t make at least a little better through the beauty that is extension methods. I’ll go into more detail on the perf counters in a future post but I wanted to share this little piece of code to help y’all get to using these a bit quicker.

/// <summary>
/// Enables and disables performance counters for a query. 
/// </summary>
/// <param name="query"></param>
/// <param name="enabled">true to enable, false to disable.</param>
public static void SetPerformanceCounters(this Query query, bool enabled)
{
    
    Uri queryUri = query.Name;

    DiagnosticSettings settings = query.Application.Server.GetDiagnosticSettings(
                        queryUri);
    if (enabled)
    {
        settings.Aspects |= DiagnosticAspect.PerformanceCounters;
    }
    else
    {
        settings.Aspects &= DiagnosticAspect.PerformanceCounters;
    }

    query.Application.Server.SetDiagnosticSettings(queryUri, settings);

}