Request timed out frequently

Question

I face the following problem time after time and i don't know how to fix it ..

I get the following errors frequently , and i had to restart the IIS or republish to fix the problem temporary :

Error Message:Request timed out.
Error Message:ERROR [08S01] [Informix .NET provider]Communication link failure.
Error Message:Thread was being aborted.

I try to make :

<httpRuntime executionTimeout="600" />

but still the same problems !!

---

Stack Trace:
   at System.Web.HttpContext.InvokeCancellableCallback(WaitCallback callback, Object state)
   at System.Web.UI.Page.AsyncPageBeginProcessRequest(HttpContext context, AsyncCallback callback, Object extraData)
   at ASP.appmaster_aspx.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object data)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

---

My PageLoad :

 protected void Page_Load(object sender, EventArgs e)
        {


            if (Session["emp_num"] != null && !string.IsNullOrEmpty(Session["emp_num"].ToString()))
            {
                try
                {

                    string user_setting = Personalization_DAL.CheckWidgetSettings(int.Parse(Session["emp_num"].ToString()));

                    if (!string.IsNullOrEmpty(user_setting))
                    {
                        user_flag = int.Parse(user_setting);
                    }

                    GetLinkedApp = DB_Connection_s.DB_Connection.GetLinkedAppUser(int.Parse(Session["emp_num"].ToString()));
                    if (!Page.IsPostBack)
                    {
                        //Profile
                        GetProfile();

                        if (Session["emp_app"] != null && !string.IsNullOrEmpty(Session["emp_app"].ToString()))
                        {
                            BindAvailableSystems(Session["emp_app"].ToString());
                        }

                        BindMainSystems();

                        if (GetLinkedApp > 0)
                        {
                            rlv_available_sys.Visible = true;
                            h5_app.Visible = true;
                            lbtn_addApp.Visible = false;
                            h4_app.Visible = false;
                            intro.Visible = true;

                        }
                        else
                        {
                            rlv_available_sys.Visible = false;
                            h5_app.Visible = false;
                            lbtn_addApp.Visible = true;
                            h4_app.Visible = true;
                            intro.Visible = false;
                        }
                        //Applications
                        if (rlv_available_sys.Visible == true)
                        {
                            Session["emp_app"] = GetLinkedApp;
                            BindAvailableSystems(Session["emp_app"].ToString());
                            if (user_flag > 0)
                            {
                                Get_UserApplicationSystems(1, 1, GetLinkedApp.ToString());
                            }
                            else
                            {
                                Get_UserApplicationSystems(user_flag, 1, GetLinkedApp.ToString());
                            }

                        }
                        //services
                        Get_MainSystems(user_flag);
                        if (GetLinkedApp > 0)
                        {
                            GetServiceInformation();
                        }
                        string[] statistics = TrackUser();
                        base.TraceActivity("Enter the portal", "https://" + Request.Url.Authority + "/AppMaster.aspx", statistics[0], statistics[1], statistics[2]);
                    }

                    TraceSystemsMode();
                }
                catch (Exception ee)
                {
                    string message = ee.Message;
                }

            }
            else
            {
                Response.Redirect("LoginPage.aspx", false);
            }
        }

---

My generic handler :

public void ProcessRequest(HttpContext context)
        {
            try
            {
                using(Stream photo_stream = Photo_DAL.RetrievePhoto(int.Parse(context.Session["emp_num"].ToString())))
               {
                byte[] photo_bytes = Photo_DAL.StreamToByteArray(photo_stream);
                if (photo_bytes == null)
                {
                    photo_bytes = File.ReadAllBytes(Path.Combine(context.Server.MapPath("~/images/PortalImages/"), "user.png"));
                }
                //context.Response.ContentType = "image/png";
                context.Response.BinaryWrite(photo_bytes);
                }
            }
            catch (Exception ee)
            {
            }

        }

Answer 1

This is speculation since there is a lot of referenced code that we don't get to see from that snippet posted in the question.

I am going to assume that you are not properly handling your database connections (DB_Connection_s) for a couple of reasons.

A) Fixed through reset

    I get the following errors frequently , and i had to restart the IIS or 
    republish to fix the problem temporary`

To me, this indicates that you are using all of the connections to your database up because when you restart or republish all the current connections are dropped.

B) No clear disposal

In your code, you reference DB_Connection_s, however it is not enclosed in a using block and it is not instantiated which means it is most likely a static class or method (hard to tell with no code for that reference).

Suggestion

Make sure you are always properly disposing of your database connections. They NEED to have .Dispose() called on them when finished. This is usually accomplished by taking the class that holds the context and having it implement IDisposable and then wrapping all your calls to that class with a using statement. A using statement will call the Dispose method automatically. If you prefer to not implement IDisposable you may also explicitly (not suggested) dispose of the database connection when you are through with it by calling .Dispose() directly on the connection once the query is complete.

Edit in response to newly added comments:

@just_name - From the code here in the comments, it seems to me that there could be an issue. Relying on ~DBConnection() to dispose of your connection, only calling .Close(), and not closing a stream, is what stands out to me.

i) Finalizers can take a long time

Using a finalizer to dispose of the connection can be risky because you can never be sure exactly when it is called. "The exact time when the finalizer executes during garbage collection is undefined." - MSDN Object.Finalize. This could be causing the system to wait a very long time if it has a lot of resources before any connections are disposed in turn slowing down the requests.

ii) Close is not Dispose

Although you are technically safe calling .Close() on a connection, it can cause problems in production. The reason is that the connection will close, but the event handlers will remain and sometimes if there is lazy loading involved or dynamic proxies these event handlers can hold copies of the connection.

iii) Use Dispose

a) Dispose of your connection explicitly

Always explicitly dispose of your connection, do not wait for the garbage collector to do it. The best practice way to dispose of it would be to use a using(){} block when accessing your DBConnection class. You can make a few changes to do this:

Define DBConnection to implement IDisposable so it can be used in a using block

public class DBConnection : IDisposable
{
  //other methods already in here
  public void Dispose()
  {
   //Close_Connection(); Call this if you want, but you MUST call 
   //.Dispose on your connections
   connection.Dispose();
  }
}

This will allow you to make a new DBConnection like this:

using( var DB_Connection_s = new DBConnection() )
{
 //todo: interact with database connection
}

The using block will automatically call .Dispose() when the final } is reached and dispose of the connection guaranteed. Moreover, this allows smaller transaction times to occur with the database which can increase query and request speeds if there was any queuing involved for database access.

If you do not like the using block implementation, then at the very least, change .Close() to .Dispose() everywhere that you use close and make sure that there is no possible path of execution which leads to .Dispose() not being called immediately after the database access is complete.

b) Use .Dispose() on unmanaged resources

Always use .Dispose() on unmanaged resources. There are a couple ways to do this, but the best practice way is with a using(){} block. I noticed that you could implement this in one place specifically with a stream in your code that must be handled.

This is one of the offending pieces of code:

IfxDataReader ifxDataReaders = DB_Connection.DBCmd.ExecuteReader(); 
if (ifxDataReaders.Read()) { 
 item = (int)ifxDataReaders["emp_num"]; 
} 
ifxDataReaders.Close();

I take a couple of issues with this. First, you are calling .Close() which was discussed above. Second, because this is in a try block, it is possible that ifxDataReaders can throw an exception and the program will continue to run without ever closing or disposing of the reader. This can cause many problems.

What you should do is ensure that .Dispose is always called on your unmanaged resources. You can do this with a using block (which implicitly always calls .Dispose()).

using(IfxDataReader ifxDataReaders = DB_Connection.DBCmd.ExecuteReader())
{
 if (ifxDataReaders.Read()) { 
  item = (int)ifxDataReaders["emp_num"]; 
 } 
}