More Asynchronous Stuff

We've divided up the project, and I have selected a new (and exciting?) role for myself: the UI developer. Web UI, that is.

Taking a look around at popular sites, I can tell you already that I need to learn all about making good use of AJAX. Let me attempt to define it, based of course on an acquaintance of less that three weeks.

Traditional ASP and ASP.NET sites are heavy on the server-side processing. For any event you want to handle, the page needs to post back to the server and be loaded again. If your page is large, that's a lot of work. There are ways to pare down on page size (by making only the necessary controls ViewStateEnabled, for one thing), but the bottom line is a page reload for every click of a button. This means slow loading, flickering, and a choppy user experience.

Popular sites are developed by people who know what their audience wants. And while I am not yet a developer of a popular site, I can tell you right now what my audience wants: a site that loads quickly and that doesn't flicker. (Or hang up. Or crash their browser. More on those in a minute.)

Enter AJAX, a technology that was available as an add-in in Visual Studio 2005 and is a charter member of Visual Studio 2008. With AJAX, you can integrate Javascript asynchronous event handling into your page. The Javascript handlers asynchronously call server-side functions (exposed via .asmx web service or WCF - and one other method, for another post). The user continues interacting with a living, breathing page while the Javascript's spare thread waits for a response from the server; when the response arrives, the main thread updates the page accordingly and all is well. Mostly.

Note that I said the handlers asynchronously call server-side functions. The call is asynchronous; the server-side functions are not necessarily. What does this mean to my end-user? What does this mean to me?

The trouble comes in when the server response takes a long time. If many requests come in, and enough of them are taking a long time, then my server will run out of threads and my site will hang up. (Remember what I said? My users won't want that.)

The solution, my friends, is easier said than done: implement asynchronous calls where appropriate on the server side. For example, if my service function is doing I/O with the data store, the call to the DAL should be asynchronous. That way, the thread working on that service call can sleep instead of "busy waiting" and free itself up for another service call (maybe one that doesn't need any heavy I/O).

Sounds great in theory. What about in practice?

I think I'll go practice...

WCF Timeouts

Did you ever search all over the web and only find the same wrong answer, over and over? I recently had this experience.

In an unrelated project, I was trying to set up a notification system using WCF. At some unspecified point in time, the web service would receive a notification for the client and would need a way to propagate that notification. Our thought had been to implement this with asynchronous calls to the service.

When using Visual Studio's very handy WCF creation environment, immediately after building your WCF app you can have another project in the same solution discover it. The client project can then choose to implement the WCF service function calls "asynchronously" (this is a checkbox in the configuration dialog for adding/changing a service reference).

Now, let's get this straight once and for all: the call to the service is NOT asynchronous. When you add in the asynchronous operations, what ACTUALLY happens is that the generated client class creates a new thread to handle the call, then has that thread notify your main thread when the call returns, so that the function call is asynchronous to your client program. But the actual call to the server is synchronous and will time out in a minute. Let me stress, in ONE minute.

The default operation timeout on a WCF client channel is 00:01:00. And contrary to popular misinformation, the settings in your .config file have nothing to do with this. The error message itself includes this line:

Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property)

That being the case, your "asynchronous" call has exactly a minute to be notified and return with the goods, or you are catching an exception. How to increase the operation timeout? By casting the channel to IContextChannel.

I admit that though my reading comprehension skills are at least average, I missed the tip in the error message and wasted hours playing with .config files, just as the forums suggested. Until I found this:

http://www.codeproject.com/KB/WCF/WCF_Operation_Timeout_.aspx

Yes, the error message had it right.

Since we're working with the autogenerated client class, it would be unwise to go into the (hidden) Reference.cs file that contains the ServiceClientFoo class. Note, however, that ServiceClientFoo is a partial class. So we can make our own file, call it ServiceClientFoo.cs, and open the class from there:


    public partial class ServiceFooClient : System.ServiceModel.ClientBase<CurrNamespace.ServiceFooRef.IServiceFoo>, CurrNamespace.ServiceFooRef.IServiceFoo
    {
        public IServiceFoo SetOpTimeout(TimeSpan timeout)
        {
            ((IContextChannel)base.Channel).OperationTimeout = timeout;
        }
    }