5

我一次又一次面临以下问题，我不知道如何解决它..

我经常收到以下错误，我不得不restart the IIS或republish临时解决问题：

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

我试着做：

<httpRuntime executionTimeout="600" />

但仍然是同样的问题！

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)

我的页面加载：

 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);
            }
        }

我的通用处理程序：

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)
            {
            }

        }
4

4 回答 4

9

这是推测，因为有很多我们无法从问题中发布的代码段中看到的引用代码。

我将假设您没有正确处理数据库连接 ( DB_Connection_s) 有几个原因。

A) 通过重置修复

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

对我来说，这表明您正在使用到数据库的所有连接，因为当您重新启动或重新发布时，所有当前连接都将被删除。

B) 没有明确的处置

在您的代码中，您引用DB_Connection_s了 ，但是它没有包含在 using 块中，也没有被实例化，这意味着它很可能是一个静态类或方法（很难判断没有该引用的代码）。

建议

确保您始终正确处理数据库连接。他们需要在完成后调用 .Dispose() 。这通常是通过获取包含上下文的类并实现它IDisposable，然后使用 using 语句包装对该类的所有调用来完成的。using 语句将Dispose自动调用该方法。如果您不想实现IDisposable，您也可以.Dispose()在查询完成后通过直接调用连接来显式（不建议）处理数据库连接。

编辑以响应新添加的评论：

@just_name - 从评论中的代码来看，在我看来可能存在问题。依靠~DBConnection()处理你的连接，只调用.Close()，而不是关闭一个流，这对我来说是最突出的。

i) 终结器可能需要很长时间

使用终结器处理连接可能会有风险，因为您永远无法确定它何时被调用。“垃圾回收期间终结器执行的确切时间未定义。” - MSDN Object.Finalize。如果在处理任何连接之前有大量资源，这可能会导致系统等待很长时间，从而减慢请求。

ii) 关闭不是处置

尽管您在技术上调用.Close()连接是安全的，但它可能会导致生产问题。原因是连接将关闭，但事件处理程序将保留，有时如果涉及延迟加载或动态代理，这些事件处理程序可以保存连接的副本。

iii) 使用处置

a) 明确地处理你的连接

总是明确地处理你的连接，不要等待垃圾收集器去做。处理它的最佳实践方法是using(){}在访问您的DBConnection课程时使用块。您可以进行一些更改来执行此操作：

定义 DBConnection 以实现 IDisposable 以便它可以在 using 块中使用

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();
  }
}

这将允许您像这样创建一个新的 DBConnection：

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

.Dispose()using 块将在达到final 时自动调用，}并保证释放连接。此外，如果数据库访问涉及任何排队，这允许数据库发生更短的事务时间，这可以提高查询和请求速度。

如果您不喜欢 using 块的实现，那么至少，更改.Close()到.Dispose()您使用的任何地方 close 并确保没有可能的执行路径导致.Dispose()在数据库访问完成后不会立即被调用。

b).Dispose()在非托管资源上使用

始终.Dispose()在非托管资源上使用。有几种方法可以做到这一点，但最佳实践方法是使用using(){}块。我注意到您可以在一个地方专门使用必须处理的代码中的流来实现这一点。

这是有问题的代码之一：

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

我对此有几个问题。首先，您正在调用.Close()上面讨论的内容。其次，因为这是在 try 块中，所以 ifxDataReaders 可能会抛出异常并且程序将继续运行而无需关闭或处置阅读器。这会导致很多问题。

您应该做的是确保.Dispose始终在您的非托管资源上调用它。您可以使用 using 块（隐式始终调用.Dispose()）来执行此操作。

using(IfxDataReader ifxDataReaders = DB_Connection.DBCmd.ExecuteReader())
{
 if (ifxDataReaders.Read()) { 
  item = (int)ifxDataReaders["emp_num"]; 
 } 
}
于 2012-07-09T23:53:59.350 回答
2

我知道它不属于 ，Error Message:Request timed out但它可能与Error Message:Thread was being aborted.. 因此，由于我们没有任何代码示例，我认为Response.Redirect("aPage.aspx")当它是在 Try-Catch 块内制作时，可以认为它可能是一个问题。

如果是您的情况，请尝试在Response.Redirect方法的 EndResponse 参数中添加“False”，如下所示：

try {
    // [... SOME CODE ...]
    Response.Redirect("aPage.aspx", False)
} catch (Exception e) {
    // [... YOUR CATCH ...]
}
于 2012-07-05T20:51:43.857 回答
2

因此，我赞成 Zia 的评论，建议您单独运行这些部件以隔离超时。Informix 连接是否有可能出错？

数据库查询有两个超时，连接超时和命令超时。这些都不会使用executionTimeout值。我没有尝试使用 Informix 提供程序，但是如果服务器繁忙或命令对象等待长 SQL 查询运行，我会增加连接对象的超时时间。

这是在 Informix 连接对象上设置 connectionTimeout 的链接... http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=%2Fcom.ibm.net_cc.doc%2Fcom .ibm.swg.im.dbclient.adonet.ref.doc%2Fdoc%2FDB2ConnectionClassConnectionTimeoutProperty.htm

于 2012-07-06T13:53:07.177 回答
2

主要问题是，为什么要花这么长时间？为什么某些页面的点击时间会超过 30 秒？你真的可以用这么慢的网站生活吗？

我们必须看看如何降低性能，以便请求在 30 秒内完成。

可以分享一下代码吗？让我们看看代码的瓶颈在哪里。

于 2012-07-09T15:08:25.853 回答