A couple new websites coming online soon

I have a few new websites coming online soon. They all have more work to setup but the basic design elements are there.

David Lemke Photography – An amazing photographer in the Southeastern Wisconsin area.

Party On The Go – A party bus company from the Madison, WI area.

First Lutheran Church – A church website that should bring their site more up to date.

Prevent jQuery UI Autocomplete from selecting on a hover when hitting enter

Whew. Long title… but it’s a very specific problem I had. While implementing jQuery UI Autocomplete I noticed that whenever a users mouse would click into the textbox and stray slightly lower it would highlight one of the values automatically:

This is fine until the users hits Enter. The Autocomplete plugin will select the word they are hovering on and continue with the current action of submitting the form. Woops.

The Autocomplete plugin has a “focus” event and a “select” event:

$( ".selector" ).autocomplete({ 
   focus: function(event, ui) { ... } 
});
$( ".selector" ).autocomplete({
   select: function(event, ui) { ... }
});

After stepping through this event via Firebug I noticed that the “Event.Keycode” value is “undefined” (or 0 in Chrome/Safari) when a mouse is hovering over the values. I setup a global variable to remember if the value being selected was on a hover or via the keyboard (up/down arrows). Then when the “select” event is raised I use that value to select what they typed, or what is selected in the autocomplete. The code is not as elegant as it could be but here is the final code anyways:

    var isHoverSelect = false;

    $("#txtHeaderSearch").autocomplete({
        source: function (request, response) {
            ...
        },
        focus: function (event, ui) {
            if (typeof event.keyCode === 'undefined' || event.keyCode == 0) {
                isHoverSelect = true;
            } else {
                isHoverSelect = false;
            }
        }
        select: function (event, ui) {
            var trulyClick = false;
            if (event.originalEvent.originalEvent.type == "click") {
                trulyClick = true;
            }

            if (trulyClick == false && (event.keyCode == 9 || (isHoverSelect == true && typeof event.keyCode != 'undefined' && event.keycode != 0))) {
                //just tabbed or hovered and hit enter
                event.preventDefault();
            } else {
                $("input#txtHeaderSearch").val(ui.item.value);
                $("#btnHeaderSearch").click();
            }
        }
    });

WCF and HTTP Keep Alives

I was working with a old ASP website that relied heavily on WCF. We would see errors firing on the client side but never on the server side. We started seeing these errors logged about 20-30 times a day:

Number -2147012866: The connection with the server was terminated abnormally
File: /classes/Class.SoapHelper.asp
Line: 71

Perfectly descriptive asp error. I tried correlating the times of the errors to other system logs, event logs, performance logs, IIS recycles, db performance, etc. I could find anything that correlated. That basically let me to the belief that the WCF service wasn’t erroring out and it completed the operation normally.

After about 2 days of research, digging the bowls of the internet, and some deduction I narrowed it down to HTTP keep alives. You might ask how the heck does that matter?

A-Ha Moment

First an explanation on what an HTTP Keep Alive is:

Most Web browsers request that the server keep the client connection open while the server sends multiple elements (.htm files and .gif or .jpeg files) to the client. Keeping the client connection open in this way is referred to as an HTTP Keep-Alive. Keep-Alive is an HTTP 1.1 specification that improves server performance by not having the normal handshake for every object. This connection is open for a certain amount of seconds after the first request, then closed on the server side.

When the ASP pages were calling the WCF service it was opening the connection, the server kept that connection open for 120 seconds (IIS6 default). The next time a call was made it would use that same open connection. Here is where my deduction came in… My theory was that executing a request at the same moment the server is closing the connection causes this “terminated abnormally” message.

In our code we use MSXML2.ServerXMLHTTP as the helper library that does all our SOAP calls for us. We used it because the regular XMLHTTP wasn’t threadsafe. It works great with one exception… it has no option to turn off the use of keep alives. After digging the internet and reading through some really crappy documentation on Microsoft’s part I came across a different library that comes with windows: WinHttp.WinHttpRequest.5.1.

The WinHttp is threadsafe and has almost the same interface as the MSMXL2  library but allows you a little more flexibility. Specifically:

xmlhttp.Option(WinHttpRequestOption_EnableHttp1_1) = False

Basically that tells this soap request to use the HTTP 1.0 protocol. The HTTP 1.0 protocol doesn’t support keep alives. In essence turning it off.

The Rub

Now you’re thinking… Wouldn’t turning off keep alives hurt performance? Your right it does. It takes about 3-5 milliseconds to do the http handshake. Add that onto every soap call our pages make it adds up. But would you rather have failed connections or 3 milliseconds longer? Yes, I’ll take reliable messaging.

The Test

I couldn’t replicate the initial issue in the test environment at all. After moving it to production… wouldn’t ya know… no errors all day. Bingo!

After realizing errors wern’t showing up in the ASP pages I started digging through our .NET site logs. Look what I found about 10-15 times a day:

System.ServiceModel.CommunicationException: An error (The request was aborted: The request was canceled.) occurred while transmitting data over the HTTP channel. ---> System.Net.WebException: The request was aborted: The request was canceled. at System.Net.HttpWebRequest.GetResponse()

Doesn’t that look familiar? Yup. After googleing this error I came across something similar to the keep alive issue. The fix for the ASP.net pages is a little different. With WCF you have to change the binding from “BasicHttpBinding” to “CustomBinding”. Once you have that you need to set  these flags on the CustomBinding:

keepAliveEnabled="false" allowCookies="false"

After digging in a little bit more about WCF and keep alives, Microsoft even recommends turning this off in a load-balance scenario. I wish they would have found that earlier.

Hello world!

I’m starting this blog as a place to post my most favorite thoughts. Mainly programming thoughts with a mix of awesome technology and family.

I found that I writeup good articles to send to my co-workers that only they see (or they ‘say’ they see them when really they have the auto-delete rule setup for my stuff). Stuff that I’ve researched and spent many hours on needs to be available for the general technology community.

Let the knowledge sharing begin!