查找ASP.Net超时原因（在漫长的操作过程中）

我有一个asp.net web应用程序。它通过WCF与业务层进行通信。有一个冗长的数据库操作（花费两个小时）。这是一个通常的同步呼叫。最初我曾经习惯了与WCF超时相关的异常。对于这些例外情况，以前在UI页面中引发了异常（称为“套接字超时”）。我在服务和客户端都使用WCF绑定设置解决了这个问题。查找ASP.Net超时原因（在漫长的操作过程中）

现在，（正好）一个小时后，我在浏览器窗口中出现错误。即使我们的应用程序有一个自定义的应用程序错误页面，它也不会显示自定义错误由于在UI中没有抛出异常，我认为它可能是由于ASP.Net超时而不是WCF造成的。我也没有看到任何相关的登录事件查看器。

我可以使用哪些方法/工具来确定超时的确切原因？

它是broswer设置/ asp.net设置/ iis设置问题？

IE错误信息：您正在查找的页面当前不可用。该网站可能遇到技术问题，或者您可能需要调整浏览器设置。注意：在底部显示“无法找到服务器或DNS错误”

注意：该功能仅在一个月内使用一次。这是管理员的功能。所以花两个小时对我们来说没问题。

注意：我有以下WCF配置。服务（receiveTimeout =“05:30:00”）和客户端（receiveTimeout =“05:30:00”和sendTimeout =“05:30:00”）。

注意：无法导航到我们的自定义错误页面，并且不会引发异常。

注：我使用Visual Studio 2005开发

注：WCF是自托管的测试。

注：在WCF NetTcpBinding的

在应用程序中使用的一些配置值列举如下：

<httpRuntime maxRequestLength="20000" executionTimeout="900"/>

<forms loginUrl="Default.aspx" name=".ASPNETAUTH" protection="None" path="/" timeout="30" defaultUrl="Home.aspx"> 

    </forms> 

</authentication>

和 -

<roleManager defaultProvider="MyRoleProvider" enabled="true" 
cacheRolesInCookie="true" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All"> 
    <providers> 
    <clear/> 
    <add name="MyRoleProvider" type="My.AccessControl.ServiceLayer.MyRoleProvider" /> 
    </providers> 
</roleManager>

注：我是计划在IE中禁用'“显示友好的HTTP错误消息”。我还计划在system.web中使customErrors mode =“Off”对其进行进一步测试。

来源

2011-06-21 Lijo

考虑把它分成独立的过程一个Web请求是不是要住2个小时... –

这是如何托管，在iis？还是开发者服务器？如果它在iis中可能检查你的连接超时设置 –

你是否使用不同的浏览器得到相同的结果？ –

如果您可以托管它在IIS服务器上，您可以尝试使用FailedRequestTracing模块。

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

我已经使用了故障排除

之前超时。

来源

2011-06-21 19:20:22 snaits

当然，我会尽最大努力用FailedRequestTracing进行测试。与此同时，请您提供一些配置值，以便我可以查找潜在问题（可能是1小时的默认设置）？ – Lijo

会话是否超时或在一小时内关闭（网络）应用程序？

来源

2011-06-21 21:01:42

第一个，浏览器只会等待这么长时间才能让Web服务器响应并开始产生响应。 IE 7/8，我相信60分钟后保释。关于IE 9不知道。详情请见KB181050文章。在决定在服务器上没有服务器之前，Firefox，Chrome，Safari，Opera都可能会在多长时间内愿意等待。

坦率地说，我认为在决定服务器不会回答之前，60分钟等待很长时间。 5分钟应该足够了。如果您要求网页并且没有收到服务器超过一两分钟的任何响应，那么您会假设什么？您是否通常认为服务器已被绑定并取消请求？

无论如何，当浏览器放弃请求时，它将关闭套接字，您将从浏览器中获得错误页面。你不会在服务器端看到任何东西：它仍然欢快地磨掉。不过，我认为，IIS会在套接字丢失时发现。希望在那时IIS将终止请求。

第二个，IIS本身只会等待很长时间，然后才决定在请求处理过程中出现问题。我相信你应该得到一个例外。

为什么你会期望你的用户（和他们的网络浏览器）在HTTP请求上等待2+小时呢？

设置您的管理应用程序，以便像这样的请求排队并通过某种守护进程异步处理（或产生一个线程来执行异步处理。回传某种票据，以便请求页面可以定期轮询以查看如果长时间运行的请求已经完成：在这一点上，返回任何构成请求的实际响应。

在客户端浏览器上，通过AJAX帖子产生这样的请求。让客户端JavaScript使用返回的票证每隔30秒钟轮询一次，直到请求完成。Voila！没有更多浏览器超时。

来源

2011-06-21 21:27:30

您最好需要实现双工服务WCF和ASP.net和AJAX之间通知客户端和网络服务器之间的通知

来源

2011-06-21 21:28:48 hungryMind

通过HTTP等待您自己描述为两小时操作的整个概念从git-go中是有缺陷的。正如其他海报所提到的，你需要重新思考你的策略。在一些排队过程中踢出它，然后向用户提供一些方法来轮询完成，甚至向他们发送带有链接的电子邮件通知是一种方式。

跟随流程。

来源

2011-06-21 23:05:29

查找ASP.Net超时原因（在漫长的操作过程中）

回答

相关问题