robKitson.net - Journal

The operation has timed out

Friday, November 13, 2009 at 12:41AM

Actually, it said 'System.Net.WebException: The operation has timed out'... and it said it a bunch of times. I swear the error log was laughing at me.

Working in C# (.Net 3.5) tonight and had to write a method that contacted a few other sites and downloaded some data. Simple enough, just loop through the urls, setup the request, get the response and process.

foreach(var url in urls)
{
    var request = WebRequset.Create(url);
    var response = request.GetResponse();
    //... do something with the response
    response.close();
}

Worked like a charm for the first run, so I let it go. Came back 15 minutes later to a log file full of errors telling me that 'The operation has timed out.' So, with just a little bit of research I found this post which points out that without a call to request.Abort() you start running into this problem.

So, I added a finally{} block with a request.Abort() in it and everything's been fine. I have to admit, it feels like a bit of a hack, so I think I'm going to have to do some more research. Will update here when I know more.

Update:

I found a post on a form that mentioned that setting the HttpWebRequest.KeepAlive might be an issue. According to the post, when it is true (it's default) it keeps a connection to the remote Url in a connection pool, so that it can quickly hit it again if it has to. And, if the remote server's keepalive is set to a shorter interval it will close the connection before the WebRequset does, so when the WebRequest tries to use the same request again it throws because it thinks it's getting an open connection to the server.

I tried commenting out the request.Abort() and adding ((HttpWebRequest)request.KeepAlive = false; but ran into the same exact issue about 90 seconds into my tests. So I'm putting the Abort() hack back in until I get some better info.

Using FluentNHibernate and Rhino-Commons – Part 2

Thursday, February 19, 2009 at 7:54PM

In Using FluentNHibernate and Rhino-Commons – Part 1 I shared how to leverage INHibernateInitializationAware in order to get your FluentNHibernate configuration into the SessionFactory in your UnitOfWork. In part 2 I’m going to show you how to do the same thing using the latest changes (r328) to FNH.

I was looking at the new FluentNHibernate site earlier and noticed (in the Wiki) that they added a new class called ‘Fluently’ to help assemble the NHibernate configuration. The first thing that I noticed is that I needed to find a way to get the mappings into the Configuration that I am passing into the FluentNHibernateInitializationAwareConfigurator that I’ve been using.

public class FluentNHibernateInitializationAwareConfigurator : INHibernateInitializationAware  
{  
    public void BeforeInitialization(){}  
    public void Configured(Configuration cfg)  
    {
        Fluently.Configure().Mappings(m =>
        {
            m.FluentMappings.AddFromAssemblyOf()
                .AlterConventions(convention =>
                    {
                        convention.GetForeignKeyName = (prop => prop.Name + "Id");
                        convention.GetForeignKeyNameOfParent = (prop => prop.Name + "Id");
                    }
                );
            m.Apply(cfg);
        });
    }  
    public void Initialized(Configuration cfg, ISessionFactory sessionFactory){}
}

This is actually a simplified version of what I am using, which is actually currently leveraging the AutoMapping features against entities in two different assemblies (although the example above is using FluentMapping). I will probably create my own FluentMappings once the domain gels a bit more so that I can have more granular control over the database structure.

However I decide to create my mappings (Fluent, Auto, classic HBM files, or a combination) I’ll still be able to use the Fluently class to apply them to the configuration as long as I remember to call Apply() and pass in the NHibernate Configuration that is passed into the Configured() method in my FluentNHibernateInitializationAwareConfigurator.

Using FluentNHibernate and Rhino-Commons

Monday, February 2, 2009 at 3:19PM

Since it's inception, I have been a big fan of FluentNHibernate. I am also a big fan of Ayende's Rhino-Tools.
A project that I've been working on recently has given me the opportunity to trying to leverage both. I wanted to use DatabaseTextFixtureBase from Rhino.Commons.ForTesting with FluentNHibernate to work on my integration tests. The problem that I kept coming up against was the fact that FluentNHibernate works it's magic on the NHibernate configuration in the PersistenceModel class, and getting your hands on the NHibernate configuration once you call DatabaseTestFixtureBase.InitializeNHibernateAndIoC() Rhino.Commons works it's magic privately and you no longer have access to the NHibernate config (or not in a way that I could see).

As it turns out, my last assumption was wrong. I asked the Rhino-TOols list how I might go about accomplishing this integration and in as simple a response as I could have hoped, I got a 1-word word response from Ayende, "INHibernateInitializationAware" (and honestly, I'm glad that that was all the help that I got.) It was a simple hint but it made me go back and look at everything all over again and I saw a bunch of stuff that I hadn't looked at before. And now I'm chuckling a bit over his post from this morning about Static vs. Dynamic Dependencies because when I was looking at the implementations of INHibernateInitializationAware that are in Rhino.Commons I didn't find one that helped me understand what it's purpose was (in his words about another class, "there's not a lot happening there").

As it turns out If you register an INHibernateInitializationAware service with the container, it will be picked up by the NHibernateUnitOfWorkTestContext when it calls CreatConfigs(). So that's what I did.

public class FluentNHibernateInitializationAwareConfigurator : INHibernateInitializationAware
{
    public void BeforeInitialization(){}

    public void Configured(Configuration cfg)
    {
        var persistenceModel = new PersistenceModel
                                   {
                                       Conventions =
                                       {
                                           GetForeignKeyName = (prop => prop.Name + "Id"),
                                           GetForeignKeyNameOfParent = (prop => prop.Name + "Id")
                                       }
                                   };
        persistenceModel.addMappingsFromAssembly(typeof(ClickMap).Assembly);
        persistenceModel.Configure(cfg);
    }

    public void Initialized(Configuration cfg, ISessionFactory sessionFactory){}
}

DRYing my UI and BYOC

Tuesday, November 18, 2008 at 9:45PM

Of course I'm referring to the Do not Repeat Yourself principle, but in this case I'm focusing on not repeating my UI development cycle.

I was working on the prototype of an application about a year ago, and found myself in the middle of an anit-pattern of sorts... change some code/properties, hit F5, click & watch, click & watch, click & watch.... not only was the process slow and painful, but in order to make it easier to test I had hacked in (and had later remove) a few extra methods which were called when the app loaded in order to fill it with test data.

A couple months ago, we decided to scrap the prototype and move on to UI version 2.0. The model and services are going to stay the same, each have a full suite of tests and satisfy their business requirements, but the UI was weak. Seeing that it was my first WinForms app, that most of my experience has been in web development, and that I had spent the last year on a console app, I didn't feel too bad about scrapping it.

The thought of redoing all that manual UI testing was too much to bear so I started googling and found a great series of articles by Jeremy D. Miller called Build Your Own CAB. In them, Jeremy does a great job of explaining how to write code which makes your UI programmatically testable by creating a contract which your UI will implement and is testable through mocking. Reading through the series, I sometimes found myself trying to figure out where all his example code would go (which project? which file? which namespace?), and whether or not there was missing code.

Looking through the comments on some of the posts, I noticed that a few other people were asking the same question and wanted a full blown .sln with a working example that they could dig into. I asked Jeremy about this at DevTeach, and told him that I was thinking about putting together some example solutions which I could use to make sure I understood the concepts, and then share them. Green lighted, I did the first 2 ( Humble Dialog Box, and Supervising Controller), and started a Google Code project called BuildYourOwnCAB.

The subversion repository can be found here: http://buildyourowncab.googlecode.com/svn/trunk/

I plan on tackling more examples soon, and would like to do one per week until I'm done. Since the project is open source I will be happy to accept patches; the better the examples are the more we are likely to learn from them.

Giving Evernote a go

Wednesday, April 9, 2008 at 8:53PM

I've been looking for a good ubiquitous note taking application ever since I read that Microsoft OneNote had a mobile client that would sync with the desktop app whenever you did a local ActiveSync between your Windows Mobile SmartPhone and your PC. After taking the time to install OneNote on my laptop and phone, I found out that when they said 'Sync' what they really meant was that any notes that you type into OneNote on your phone will be copied into a special section in OneNote on your desktop, and from there you can sort them into their appropriate categories. All in all it felt clunky, so I never used it.

I took a step back and asked myself why I was disappointed and what features would make me happy. I realized that the feature I've been looking for more than anything is the ability to access my notes from just about anywhere: My new work machine, my rapidly aging Dell Precision M90 development box at home, the family Mac Mini, one of the many laptops that the wife-to-be's newly formed company are using, or my new AT&T Tilt. So, when I came across a post about Evernote on TechCrunch a few weeks ago, I decided to give it a go.

The fat client has now been installed on all the machines where I spend more than a couple'a minutes per day. I'm going to be shelving the Moleskine notebook for a few weeks to roll exclusively with Evernote to see how it works out. I'll post a follow up at the end of the month, but in the mean time I may have a comment about it on Twitter.