我们的日志正在报告ThreadAbortException
,它们以看似随机的间隔停止我们的Quartz.NET作业。根据我的理解,这通常不会由线程本身正在做的事情引起(例如从FTP服务器读取文件,或执行LINQ to Entities查询),而是因为某些外部进程告诉线程停止。此外,创建日志的方式使我相信当我们收到这些错误时,整个Web应用程序正在重新启动,因此我猜测重启过程是导致线程首先被中止的原因。 / p>
所以我的问题是:如何弄清楚服务器/应用程序重启的原因?是否有某些日志会在每次重启时向我提供详细信息?我应该调查是否有这样的常见原因?
提前感谢您的帮助。
修改
我刚与一些同事讨论过,听起来IIS会在一段时间不活动后自动将应用程序置于睡眠状态,这可能是问题的一部分。通过一些研究,我发现了IIS中工作线程的“空闲超时”设置。我认为当应用程序在一段时间内没有处理任何请求时,它会发出一个shutdown命令。出于某种原因,Quartz没有立即关闭,而是等待下一个工作被解雇,然后系统检测到该作业的线程并在它尝试运行时将其杀死。
所以我想我们需要想出一些方法来在系统想要关闭的时候优雅地完成任何正在运行的作业,并且当它被告知时,如果它没有运行任何作业,那么Quartz实际上会关闭。有没有人有这种问题的经验?
答案 0 :(得分:4)
正如liho1eye指出的那样,问题出现在应用程序池关闭我们的应用程序。出于某种原因,Quartz显然没有立即关闭。相反,它等待下一个作业运行并关闭,这意味着正在运行的作业必须通过ThreadAbordException关闭。
我们的解决方案是双重的。首先,我们将Quartz更新为更新版本,这似乎使其表现得更好一些。其次,在Global.asax.cs的Application_End方法中,我们添加了对Scheduler.Shutdown(true)
的调用。这告诉调度程序停止触发其他触发器,然后等待所有当前运行的触发器完成,然后才允许应用程序结束。
答案 1 :(得分:1)
如果在代码中执行任何重定向而未指定Response.Redirect的endReponse参数,重定向将调用thread.Abort(),但仍会有代码要执行。这个代码变得孤立,因为线程消失了,你得到了异常。阅读:
http://www.c6software.com/articles/ThreadAbortException.aspx
修改强>
另一种可能性是causes the w3wp.exe process to crash or recycle itself未处理的服务器级异常。这可能是您提到的导致线程中止但尝试继续运行代码的外部原因。要确定是否可能出现这种情况,您的系统事件日志中会有例外。它们非常通用,但它们会清楚地列出w3wp.exe(因此您可以将其用作过滤器)。如果情况确实如此,则需要安装IIS Debug Diagnostics并设置一些崩溃监视器以捕获崩溃时发生的事情。由于它发生在实际页面生命周期之外,因此绕过了正常的异常处理。
答案 2 :(得分:1)
当然,这意味着在作业线程的实例上某处称为Thread.Abort()
。我会看一下这个Quartz的解释。
另一种可能性是你的工作线程是一个后台线程,你的应用程序池正在被回收,但我知道有关这个Quartz事情的任何信息。