none
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

    Question

  • Hi.

     

    we are accessing WCF Data Service, which through EF gets data we need from SQL Server (we are not using stored procedures). Randomly we get the following exception:

     

    “Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.”

     

    Since this exception is usually thrown after 30-40 seconds, we are assuming that it is related to SqlCommand.CommandTimeout property, which is 30 seconds by default (http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx). Now, the question is, how do we change this?

    Thanks,

     

    PV

    Wednesday, December 07, 2011 1:28 PM

Answers

  • Thanks Ryan.

    Since the timeout was happening randomly, it is hard to test it. Since we have set this value to 500, we did not have any timeouts :).

    The way we confirmed that is affecting the timeout was to reduce it to 2 seconds. That caused most of the transactions to fail (as expected), so that is the only thing we have at the moment to assume that this is a proper fix. In addition, the link you provided shows that we are on the right track, so we need to assume that this is the correct fix.

    At the same time, we do not see how increasing this value (to more reasonable number then 500, like 180 or so – the worst query, executed over night takes ~ 60 seconds) should have a negative effect on the existing functionality.

    Thanks again for your reply.

     

    PV

    • Marked as answer by PV66 Tuesday, December 13, 2011 5:46 PM
    Monday, December 12, 2011 7:06 PM

All replies

  • Anyone, please?

     

    Thanks,

     

    PV

    Thursday, December 08, 2011 12:58 PM
  • This is what we are trying at the moment. In the XYZmodel.Designer.vb file (autogenerated by the EF wizard), we have manually changed constructors for the entities class (one that inherits from ObjectContext) and added CommandTimeout = 500 as a last line. The documentation for this parameter states: "Gets or Sets the timeout value, in seconds, for all object context operations. A null value indicates that the default value of the underlying provider will be used."

    Is this indirectly setting SqlCommand.CommandTimeout? Can anyone from Microsoft confirm this?

    Any suggestion is appreciated.

    Thanks,

    PV

    Friday, December 09, 2011 12:48 PM
  • Friday, December 09, 2011 9:42 PM
  • Ryan,

    we are using EF 4.0, and the only place I have access to CommandTimeout is in XYZModel.Designer.vb file. In that file, EF wizard auto-generates public partial class XYZEntities (XYZ is the name of our entities) that inherits from ObjectContext. So, as in my post above, in the constructor(s) of that class (there are several of them) I have added CommandTimeout = 500.

    I think that is similar to what you suggested. What do you think?

     

    PV

     

     

     

    Monday, December 12, 2011 12:51 PM
  • PV,

     

    You are absolutely correct. In EF 4.1 uses the DbContext which, in turn, inherits from ObjectContext. So, the code in the link I gave you gets the ObjectCotnext instance and then sets the CommandTimeout property. Essentially, in EF 4.0 you inherit directly from Objectcontext so you skip the step of getting the Objectcontext from the DbContext instance. You should be good to go with that set in your constructor. Is this not working for you?

     

    Ryan

    Monday, December 12, 2011 3:40 PM
  • Thanks Ryan.

    Since the timeout was happening randomly, it is hard to test it. Since we have set this value to 500, we did not have any timeouts :).

    The way we confirmed that is affecting the timeout was to reduce it to 2 seconds. That caused most of the transactions to fail (as expected), so that is the only thing we have at the moment to assume that this is a proper fix. In addition, the link you provided shows that we are on the right track, so we need to assume that this is the correct fix.

    At the same time, we do not see how increasing this value (to more reasonable number then 500, like 180 or so – the worst query, executed over night takes ~ 60 seconds) should have a negative effect on the existing functionality.

    Thanks again for your reply.

     

    PV

    • Marked as answer by PV66 Tuesday, December 13, 2011 5:46 PM
    Monday, December 12, 2011 7:06 PM
  • May i know who to set the value to 500 ? 

    i have similar problem with SharePoint + nintex workflow.


    sin peow nspsharing.blogspot.com

    Thursday, July 05, 2012 3:42 AM
  • Sin, as per my previous post (see above) we are using EF 4.0, and the only place I have access to CommandTimeout is in XYZModel.Designer.vb file. In that file, EF wizard auto-generates public partial class XYZEntities (XYZ is the name of our entities) that inherits from ObjectContext. So, as in my post above, in the constructor(s) of that class (there are several of them) I have added CommandTimeout = 500.

    I am not sure if in your case you have access to this file.

    PV

    • Proposed as answer by Cookyrag 2 hours 18 minutes ago
    • Unproposed as answer by Cookyrag 2 hours 18 minutes ago
    Thursday, July 05, 2012 2:34 PM
  • I know this thread is two years old but I have started to use WCF Data Service and came up with this same problem. When you search this this post shows on top so I thought I would add my solution. Initially I used what PV suggested but you DO NOT need to edit the Designer.cs file directly , the Entity class is created as a partial Class and it calls a partial method onContextCreated() , so within you service class you can simple include the following code

        partial class XYZEntities
        {
            partial void OnContextCreated()
            {
                this.CommandTimeout = 0;
            }
        }

    • Proposed as answer by Cookyrag 2 hours 17 minutes ago
    2 hours 18 minutes ago