Have You Sampled Our Code Samples Yet?

One of the great things about coming to work for Gibraltar is learning about all of these things that I didn’t know the product could do. For example, the other day, I was asked in one of our Live Support chats about how to see the details of a web site session in progress.

Gibraltar collects a wealth of information about your running website. However, by default, you can’t analyze the data until the web server process completes.  I knew that live monitoring is one of the killer features slated for Gibraltar 3.0, but I didn’t realize that there are also very simple, workable ways to get Gibraltar data anytime you need it within the current Gibraltar 2.5 release.

As a former Gibraltar customer, when I wanted to get this data in the past, I simply recycled the AppDomain myself. I had Gibraltar configured to “autoSendSessions”, so whenever I recycled the AppPool, I’d automatically receive the latest logs.  I realize that is not the best answer for a number of reasons, but it is what worked for me, so I passed that suggesion to the customer.

A little later, our fearless leader Jay messaged me and asked why I hadn’t sent him the link to the Code Samples page, which shows how to make Gibraltar immediately send the package for the current session whenever an error is logged. Feeling a little sheepish, I admitted “Because I didn’t know we had that feature.”

It turns out, we have some pretty cool samples that do a lot of very useful things. If you haven’t had a chance to check them out yet, you should. This also got me thinking about some ways we can make our samples more visible and accessible. Stay tuned for some cool web site updates in the coming weeks.

Before I go, I wanted to suggest a slight tweak to the “Submitting Sessions on Error” sample I just pointed you to. In .NET 3.5 and later (4.0 for you VBers out there), you can take advantage of Lambda Expressions to simplify this call a little bit. The version I use looks like this:

protected void Application_Start()
{
    Log.MessageAlert += (sender, e) =>
                                {
                                    if (e.TopSeverity <= LogMessageSeverity.Error)
                                    {
                                        e.SendSession = true;
                                        e.MinimumDelay = new TimeSpan(0, 5, 0);
                                    }
                                };
}

Or for the VB folk:

Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
    AddHandler Log.MessageAlert, Sub(sender1 As Object, e1 As LogMessageAlertEventArgs)
                                 If (e1.TopSeverity <= LogMessageSeverity.Error) Then
                                     e1.SendSession = True
                                     e1.MinimumDelay = New TimeSpan(0, 5, 0)
                                 End If
                             End Sub
End Sub

This is simply some neat syntactical sugar that IMO makes your code a bit easier to read. Instead of having to follow the event handler to another method, you can see how the event is handled right there, without another method signature clogging up your code. Under the covers, the compiler will create the signature as an anonymous method, and sort everything out for you. Neat, huh?

I learn something new every day around here. Hope this little tidbit makes you more productive.