none
EF4.1 consumes all resources and forces power button stop when DB connection fails RRS feed

  • Question

  • I submitted a bug (681089) on Connect and nobody is looking at it in two weeks.

    I have discovered an EF 4.1 issue where a failed DB connect, admittedly my fault - failed to give a permission to a SS2008 login, caused my W3WP process to tank the whole OS. I have not explored whether the issue also occurs if the DB is taken offline for backups, but I suppose it is the same behavior. My client is reluctant to have me waste time/money on a show-stopper bug. We are considering the options to just dump EF as not ready for prime time.

    From the Connect bug:

    I have encountered a disturbing behavior in EF4.1. I have used a DB first approach and created a model of a database with about 15 tables all with simple primary/foreign key relationships. There are about 5 tables that contain (somewhat) static data that need to be loaded when the WCF service is called, as they are primarily look-up values. When the first ObjectContext query for the first look-up table occurs, lazy loading retrieves the values and all is well, at least under ideal conditions. The majority of the tables in the DB are primarily a "push data in" use case, very little read and display.

    The issue I have encountered is when the connection to the database can't be made. I redeployed my database and I forgot to add permissions for the AppPool to the local SQL Server DB for the new DB. On the first time I ran the test, the whole operating system came crashing down on that first DB access. The W3WP process ran up memory to the full 8GB physical RAM on my development laptop, all 4 cores of the i7 were floored, the disk drive was floored, and nothing could be done to kill any process. I had to use the power button. None of the expected fail-safe measures worked: W3WP never recycled, the OS was inaccessible to kill any processes and, I subsequently found out, SVCHOST jumped in to floor the resources when I could kill the W3WP process.

    On the next try, I brought up task manager and highlighted the W3WP process and stepped through the debugger to the first access to a table (2 rows in it). The access threw an exception which I handled, and noticed that the permission was the issue, and I re-threw all the way to the WCF service method, where I returned a FaultException. Even though I gracefully exited, the same resource behavior occurred, but this time I was able to right click, after 20 seconds, and kill the W3WP process tree. Unfortunately, the SVCHOST process picked up where W3WP left off and ran memory and disk access up to 100% and I was back to the power button. This scenario is repeatable. I am not sure if my Norton Internet Security might have some part in the SVCHOST behavior. Not even really sure why SVCHOST would go out of control in this situation...

    After adding the permission for the user in the DB, all works well. However, I cannot use this framework in a production environment where a sporadic network drop causes the crash of a production web server. My client's networks are very reliable, but one drop that causes a server, or its VM, to have to be manually recycled is completely unacceptable. I realize that I can turn off lazy loading and will try that, although I am not really sure where to do that one time where it won't get overwritten on a regen of the entities. When I get a lot of data into the non-static tables, will the eager loading mechanism load everything related?

     

    Has anyone seen this behavior and what is the mechanism to permanently remove lazy loading, or is there a workaround/bug fix in the works?

     

    Thanks,

     

    John

    Tuesday, August 9, 2011 5:07 PM

Answers

  • I have discovered the issue. During the exception handling, I was getting into a recursive exception/log/exception loop. Odd thing was, I had to remove all of the code before I could step into the exception handler to find the debug.

    Everything is going smoothly.

    John

    • Marked as answer by jhempe Friday, August 12, 2011 9:18 PM
    Friday, August 12, 2011 9:18 PM

All replies

  • On 8/9/2011 1:07 PM, jhempe wrote:
    > I submitted a bug (681089) on Connect and nobody is looking at it in two
    > weeks.
    >
     
    Are you using the "using" statement dealing with the entity connection?
    I know it's not talking about database connections. But for me, I don't
    use the "using" statement on database connections.
     
     
    I go with a explicit open and close of the entity connection with a
    try/catch/finally and take control. I don't know if you are doing that
    or not.
     
    Tuesday, August 9, 2011 5:39 PM
  • I am not using the using statement for either the WCF or the ObjectContext. I can't see how that would affect what is going on where the error occurs. I am very aware of the WCF issue the using statement creates. Let me try to be more clear:

    I am loading a table of some 2 rows that I will use for lookup throughout the application. I create an instance of the entity generated by EF41 (with the latest update applied). Here is the actual code:

                    MyStoreCloseEntities scEntities = new MyStoreCloseEntities(); // The ObjectContext

                    // Turn off lazy Loading?? Proxy Creation??
                    // Doing this to avoid the bug where lazy loading appears to consume all resources
                    // when a DB connection fails on the first access.
                    scEntities.ContextOptions.LazyLoadingEnabled = false;
                    scEntities.ContextOptions.ProxyCreationEnabled = false;
                    _cultureCds = from cc in scEntities.CultureCodes
                                  orderby cc.CultureCode1
                                  select cc;

                    if (null == _cultureCds || _cultureCds.Count<CultureCode>() <= 0)


    All is good until the last line. That would be the load location. And, since it waits until then to blow up, I am thinking lazy loading didn't get turned off...

    I am watching task manager W3WP process as I step in the debugger on the last line, and the debugger freezes for a few seconds while the connect fails. Because I have turned the DB off (to simulate a no-connect), as soon as this throws an exception which I catch about two lines below in the same method, I can see W3WP race from 104MB to 3.2GB in about 5 seconds. I have not even stepped into the catch clause yet. I kill W3WP and all seems to go back to normal (previously, if I had let this go longer where W3Wp ran up to 8GB, SVCHOST would take over and consume all memory???). Sometimes, VS2010 will tank and restart after W3WP is killed.

    If I disable lazy loading as I did above, it does not stop this and I am not really sure it actually did disable it. There is something more fundamental that is wrong with EF41 when a DB connection fails.

     

    John

    Friday, August 12, 2011 12:28 AM
  • I have discovered the issue. During the exception handling, I was getting into a recursive exception/log/exception loop. Odd thing was, I had to remove all of the code before I could step into the exception handler to find the debug.

    Everything is going smoothly.

    John

    • Marked as answer by jhempe Friday, August 12, 2011 9:18 PM
    Friday, August 12, 2011 9:18 PM